Profile cover photo
Profile photo
Dylan Powers
About
Dylan's posts

Welcome to CyanogenMod where you have to deal with stupid little bugs like the audio output suddenly deciding to not go through your headphones! At least you don't have to deal with the carrier garbage that was originally on your phone #TheStateOfAndroid

The new Moto X has me thinking. Cross carrier phones aren't really new, but the new Moto X is the first I've seen guarantee compatibility across all US carriers. If Motorola can pull this off, will we start to see more phones like this in the future? And how will this affect multi-carrier MVNO's like Google Fi? Will we start to see more of those cropping up?
These questions then make me ask, what if we took this to the next logical conclusion. Carriers need radio spectrum to improve their network, however radio spectrum is a limited public resource, and the lack of such readily available resources make it impossible for new competitors to make a splash into the market. Thus we have MVNO's. Since we have problems with coming up with ways to fairly distribute wireless spectrum to the big 4, and giving spectrum to small regional carriers is a waste, what if we forced everyone into becoming an MVNO and have the towers and radio spectrum be operated by separate entities? Then giving radio spectrum to smaller tower operators would actually be beneficial and help create meaningful competition.
I'm not much for heavy-handed government, and I do believe there is some benefit to carriers owning and operating their own towers, especially in rural areas, but if Google Fi and others prove to be reliable, who knows, maybe market forces will make this future a reality. Of course if the FCC could help push towards that future through prioritizing wireless providers that are increasingly MVNO friendly in their spectrum auctions, that would be great too!

LG G2: Should I switch back to Cyanogenmod? Yes! But I'm using this list for future reference.

Perks to CM:
* Wifi tethering works correctly
* Wireless ADB
* No nagging about music volumes
* Config profiles
* Properly manages memory
* Sane notification drawer with proper quick settings
* Non-idiotic ringtones and notification sounds to choose from

Disadvantages to CM:
* NFC broken (Only on the LS980 version of the G2 of course)
* ~~Slightly lower music volume~~ Not anymore
* Cellular connectivity can be glitchy
* Loss of native IR remote app (Can hackily install it)
* Loss of native voicemail app (Can hackily install it)
* Hangouts voice broken

Either way:
* GPS is buggy
* Call quality is non-existent
* Worsening battery life
* Camera not great
* Overall sluggishness
* Signal strength often misreported

Android immersive app pro tips:

Step 1:
Do not style your activity with <item name="android:windowFullscreen">true</item>. That will just get in your way. It's best just to handle it all in Java. 

Step 2: Follow https://plus.google.com/+DylanPowersz/posts/CmqEKvEgtaM

Step 3:
Remove jank when starting non-immersive activities (as in post-rendering of the activity, the status bar is finally registered as a piece of the screen and suddenly the UI gets readjusted) by sending the following UI flags to setSystemUIVisibility() just before running startActivity():
View.SYSTEM_UI_FLAG_LAYOUT_STABLE
          | View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
          | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
          | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION
          | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY;

Note that the View.SYSTEM_UI_FLAG_FULLSCREEN flag is missing. What this allows for is for the status bar to get a head start on appearing on the screen before everything else. I'm not sure if this is a race condition, as in a really slow phone could still show the above described jank, but it's the best solution/hack I've come up with yet and certainly better than nothing.

Pro tip, the behavior of https://developer.android.com/training/system-ui/immersive.html#sticky is less buggy if you put the code in onResume rather than onWindowFocusChanged()....unless anyone can come up with a reason not to???? Anyways, doing it as the guide says is pretty buggy

Update:
Have it in both! onResume handles cases such as screen rotations while onWndowFocusChanged handles instances of alert dialogs being dismissed.

Post has attachment
+Android Developers http://developer.android.com/guide/topics/ui/dialogs.html#AlertDialog It would be good to add a line with dialog.show() in the code sample after builder.create() to you know, show it, because that's sort of a critical step ¯_ツ_¯ Yes, you mention it in an earlier paragraph in the guide, but I'd rather just read the code.

Glad I can present a timeline of me relearning Android Activities...yay! 

2 revelations:
* setRetainInstance() on Fragments isn't working as expected. onDestroy() is still getting called when leaving the Activity.
* onCreateView() doesn't set the content view to the returned view. Instead, I still have to manually call setContentView() on the activity. What is up?!?

Some general thinking, but Android development would be made easier if activities weren't destroyed upon device rotation. Firing off some sort of resize event would seem like a better option. Maybe this is why there's a noticeable hang when rotating a device? Because everything has to be recreated?

I've got beef with this:
"Should you use a service or a thread?

A service is simply a component that can run in the background even when the user is not interacting with your application. Thus, you should create a service only if that is what you need.

If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create a thread in onCreate(), start running it in onStart(), then stop it in onStop(). Also consider using AsyncTask or HandlerThread, instead of the traditional Thread class. See the Processes and Threading document for more information about threads." - http://developer.android.com/guide/components/services.html#Basics

I don't like that summary simply because activities are destroyed and recreated on something as trivial as device rotations. That wouldn't make for a very good experience to have a piece of audio stopped just because of a device rotation. 

I'm a little confused by the following +Android Developers guide: http://developer.android.com/guide/topics/ui/settings.html#Listening It references a deprecated API: http://developer.android.com/reference/android/preference/PreferenceActivity.html#findPreference(java.lang.CharSequence)
Now I'm questioning the validity of the guide and whether it's following best practices.
Wait while more posts are being loaded