Neighbor information has always been problematic in Android. You can get 2G cell IDs, but not 3G or 4G. And the list of potential neighbors gets populated briefly just before the cell hands off. Well, it hit me one day, why not just collect -- continuously -- handoff statistics? You always know the current (serving) cell, you see who it hands off to...well, that is a neighbor relation!
So I decided to just collect, in the background, neighbor data...that is, what cell handed off to what cell. It's not perfect -- it only shows neighbor relationships the device has encountered -- but it's better than nothing which is what I have now. This is much like the coverage bubbles the app draws -- they are not necessarily the complete coverages, but the coverage areas seen by the device.
Development goes well. I'm folding the new features into others the app already had. Now I have to play with it and put in things an engineer would use.
After monitoring Google Analytics for crashes and exceptions I noticed a "View not attached to window manager" error popping up a lot. I researched this and discovered that the problem was caused by an orientation change after a site list or recorded data notes or wifi points had been requested, but before the request had been fulfilled. Basically the activity restarted and the list being generated had nothing to send the results to...so it crashed (I think the user just saw a black screen). Simple fix in the XML.
Also fixed the text box sizing problem in the sliding drawer on the map tab. I called out a fixed height knowing full well that some phones might not size correctly. Nut hey, it worked. Now I use a custom SlidingDrawer which uses a layout_height that actually works. I also custom sized the width of the buttons at the bottom.
I'm still digesting all the info coming in from Google Analytics, but this is definitely worth it. It looks like Site Optimization is used a lot more than I thought. I discovered several little bugs right after the last release, and before I went away for the holidays (naturally), and finally got to fix them today. Will issue a new update shortly.
I'm including the process for uploading site location CSV files into the database, since this seems to get requested more.
Decided to put Google Analytics in the app. Now, this may freak the more paranoid users out (the idea that there is stuff tracking the app's usage), but it's is actually incredibly useful. It lets me see not only crashes and exceptions but usage -- I can see what is actually being used in the app, and what is not.
I wanted to add something else to the app as well -- I didn't just want to throw the addition of GA since it would scare more people. In fact, the whole fear of users revolting is what caused me to add an Opt-Out item in the preferences, so everything is cool and guilt free.
And the extra thing I added? Charts in the big picture! Now the big picture of the signal strength and data activity over time is shown. The only sticky point is the x-axis labels. How do you represent time for data that may have been measured at regular intervals, but spread out over days through multiple recordings? What I did was figure the average recording interval and multiply that by the length of data points on the chart's x-axis. Still needs work, but this will do.
I think I may have found a solution to the LTE problem! Discovered that there is a crap load of info in the SignalStrength method which can be accessed by looking at the SignalStrength.toString() method. This will produce a string with space separated elements, example: "SignalStrength: 13 0 -120 -160 -120 -1 -1 99 2147483647 2147483647 2147483647 2147483647 gsm|lte 4". If you split that by the spaces, then the eight element *should* be the LTE value.
I created a "Test message" item in the list of submenus on the Main tab. It shows the unaltered values. I also created a method in my Util class that takes the RSSI value and, if the network technology is LTE, get that from the string and do the "-113 + 2 * signalStrength" calculation. I don't know if that last bit is necessary...just assuming it is. I'm going to need feedback from the users for this one since I don't have an LTE phone.
Ok, for this version I have decided to raise the minimum version number of the app from Android 2.1.x to Android 2.2.x. This will cut off about 1500 users (3.34% of active users), but I think the increased information is worth it.
After working out a few ideas I came up with a pretty nice looking chart. It shows traffic, in bytes, for transmit and receive data where transmitted data is represented by a bar graph above zero, and received bytes are a bar graph below zero.
There is also a new traffic group in the Main window showing Mobile and Total transmit and receive bytes. I haven't figured out what "Total" actually means yet, but as soon as I do I'll put that info to use.
Now for more testing!
Well, after figuring out how to create my own View, it hit me that I could place that View anywhere. In this next release I am adding the XY line chart to the recorded data playback. This is a really wonderful addition allowing you to see the signal strength profile for your data in addition to the Map info. This chart, like the Chart tab, displays RF handoffs and technology changes. It will not show the legend in the upper left corner, or wifi data (that may change).
As you can imagine the screen can get a little cluttered so I added a Menu option to turn the labels above and below the signal strength line off. The x-axis time scale is approximate. What I do is sample about 200 points and get an average time span between those points. I then calculate, roughly, the time scale. This is necessary because recorded data may or may not be on a fixed interval, and under standard recording the app only inserts data if you are actually moving.
And finally, I changed the sleep settings for the app. Before, the app's screen would dim (but not turn off) after a period of time. Now, the app will stay on full while in Map, Main, or Chart (any recording screen).
Finally figured out the chart and timing issues! Currently in the process of testing the components, but the chart displays signal strength over time with the time scale adjustable from 30 seconds to 5 minutes. RF signal strength is displayed in green and wifi is shown in magenta. The wifi curve is the strongest hotspot in range. Also indicated are the handoff and technology changes made on the RF curve and the strongest indicated hotspot.
Added a timed interval recording feature. Normally, a new record is entered provided a minimum GPS time and distance has elapsed. Also, no record was ever recorded if the mobile location has not changed. This keeps record size down to an absolute minimum. Now, with timed interval recording, a new record is added after a specified time has elapsed regardless.
Hard at work on the latest update. First, after numerous emails about this I've finally decided to add timed interval recording. Right now the app records data only if you are moving. This is Drive-testing 101 -- why continue to record data if you are sitting in a traffic jam, not moving or moving very slowly? This also keeps the data files from blowing up. Well, since users seem to want it I'm working out a way to add this. Basically, the app will insert data at 5, 10, 20, or 30sec intervals (still working that little bit out). The trick is getting that to work with the current method.
The second slightly more exciting addition is a charted display of signal strength! I've toyed with this idea for a while (and have wanted to do a chart ever since I started programming in Android), and now I have it. Took a while to hunt down the basic code for how to create a chart, then how to create an animated chart (it's going to be signal strength over time), but I got it. I'm currently working on handoff and technology indicators, and a nice way of displaying the current cell.
Ran into a couple brick walls. One was binding an activity to a service, and the other has been using a custom view. I thought binding would be a no-brainer -- there is so much example code out there it's not funny. But -- typically -- try as I might, I could not get it to work. I was literally copy-and-pasting the code into my app and it wouldn't work! I finally gave up when I thought that it really wasn't adding anything substantive to the app -- and what I was contemplating would have just complicated things down the line. I've put the View thing on the back burner until I get some of the major bugs of the chart worked out.
This is going to take a lot of testing/debugging.
I see this sometimes: users asking directly or through the comments section, why there needs to be so many permissions. A lot of users are understandable nervous about letting these apps get to this information and don't always understand why the app may need THAT much access. I try to explain in the new Permissions section why this is.
What many may not realize is that to do certain small things within the app, some rather broad permissions must be granted. You can blame Google if you like. For example, saving a simple file requires the "Storage" permission with its rather ominous subtitle stating that you are granting the app the ability to: modify/delete USB storage contents!!
Images of the app going on a rampage, deleting and altering critical files comes to mind. Well, rest assured, Google tried to be a little smart in this regard -- all apps play in their on sandbox and cannot screw with other apps or their data.
But there are limits to even Google's genius and I try to spell out what the app does and does not do on this page