In your list, item 6, do you call it Extension2 because it should initialize a new push provider subclass when it joins the 2.5 ghz network? Just asking to confirm.
I expect to create a new process, not just a new subclass. Stepping back for a moment, this is how the push provider life cycle actually works:
- Device joins a matching network.
- Extension is launched, start called.
- Extension runs
- Device leaves the matched network.
- Extension stops and is then terminated.
- <time passes>
- Device joins a matching network, process begins again at #2.
That leads me to here:
initialize a new push provider subclass
One of the common mistakes I see developers make is not being aware that their extension is regularly going to be terminate/launch and then misunderstanding what the data they're looking at actually means. For example, trying to "actively" debug a push provider extension is only useful under very specific circumstances (for example, when you're targeting a specific, known failure). In broader testing, the debugger just gets in the way, causing you to miss secondary launches or event preventing those secondary launches at all. Once your extension basically "works", testing and debugging needs to be done through log data to avoid disrupting the entire system your trying to test.
Related to that point, I strongly recommend creating your own stand alone log architecture that:
-
Logs your messages to your own file (so you can easily trace what "you" did)/
-
Logs the same messages to the system console (so you can easily correlate your own activity against the broader system).
-
In your own logging, includ the current pid (process id) in every log message, typically as the first value in the log message.
On that last point, if everything is formatted properly, it's easy to filter out when scanning an extended log but any change still tends to "jump out" when your scanning a log. It takes up minimal space and I've seen way to many cases where it was the one detail that suddenly made everything clear.
All that leads back to here:
We do not get a subsequent call to init and start(), the extension just sits there waiting.
How are you tracking this "waiting"? Do you just mean that your log doesn't show it starting again, or do you mean that your doing some kind of "active" monitoring? My concern here is what I talked about with the debugger above- many forms of "active" monitoring can prevent the extension from terminating, which will then prevent the "next" launch.
Similarly, expanding on this point:
We've tested it and the phone connects to the 2.4 GHz network.
The part that can be tricky here is that it's entirely possible for a device to:
-
Be "on" a Wifi network, in the sense that "the device is aware of the network and making some effort to use it".
-
The communication quality to be so poor that the device doesn't actually consider the network truly "working" and may not have even launched your extension.
Keep in mind that this is not a theoretical concern. I've seen many real world networks where there was a surrounding "band" of several feet where an iPhone could clearly receive from the AP but the AP was basically incapable of receiving from the iPhone, leaving the device "stuck" in the state above.
This kind of issue is why I specifically recommend this kind of testing:
For testing purposes, I'd actually keep the device stationary and well "inside" the 5ghz zone, then replicate #2 by just turning off the 5ghz radio.
...as it removes all radio variability from the testing process. Radio variability is not something your app can do anything about, so need to make sure it isn't distorting any testing you do.
Another concern I have is here:
we have UI in our app that shows that it's able to connect to the internet.
One of the mistakes I've seen over and over again when looking at this kind of issue is assuming an underlying failure based on relatively vague data without having actively investigated what was ACTUALLY going on. Case in point, it's easy to see how this would "look" like a problem:
-
Device shows WiFi connectivity on the screen*.
-
App is able to connect to your server.
-
Local Push Connectivity Extension is NOT running.
...but that is NOT necessarily the case. The state above is normal and expected if:
-
The Wifi radio is stuck in the state I described above.
-
App is using one of our "modern" network APIs.
Your app is actually connecting over cellular, not Wifi, and the system hasn't launched your extension because it's (correctly) assessed that the Wifi network does not in fact "work" (yet).
*You could argue that the device shouldn't show connectivity before the network "works" however, in practice, this is a case of trying to pick the option that will least annoy users.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
