Commence the blah.
I would like to use this post to discuss the methods presented in the article on Android presenters and how to save their state in the application via the Android Loader framework. You can find the post on Medium about this, here.
Over this past weekend I attempted to use this solution to handle saving the state of presenters in PadLock. At the end of these trials I have found a couple of points why I would advocate for, and against preserving Presenters in this way, and most importantly, why I ultimately would not recommend this method.
The pro of this method is the fact that because Loaders are preserved between orientation changes and cleaned up after the lifecycle ends, you do not have to worry about leaking the view that the presenter is attached to or manually clean up the presenter yourself.
I would address this by stating that you should be keeping a Weak Reference to your view in the presenter, not a strong one, which would automatically unbind the presenter from your View whenever it would normally be cleaned up.
The major cons I see in this method of preserving your Presenters through a custom Loader implementation, is that if you wish to use your presenter, it is only guaranteed available in all cases after onStart() in your Activities, and onResume() in your Fragments. While the presenter is available in onStart() for the first time it is used in Fragments, it is not guaranteed at any onStart() call thereafter, making the first guaranteed time in Fragments onResume(). By using Loaders, you sacrifice doing any important work relating to your presenter in onCreate(), onDestroy(), and other areas of the lifecycle that it is not guaranteed to be available. In my opinion, it is not very useful to have the presenter be managed in the lifecycle if it cannot be used for more than half of the Activity/Fragment lifecycle anyway.
To compound onto what I see as the major con to this approach, the ability for the Loader to preserve state is currently broken making it not worth your time at this point. Note that even if the Loader were to be fixed in the future, the above con still stands as my main reason for not advocating this method. Loaders also deliver results on orientation change twice by design, making using them to preserve state effectively a bit of a hack around as well.
Because of the various issues which surround the use of Loaders for preserving Presenter state, I currently take an approach which relies on a headless retained fragment to save arbitrary objects into a SparseArray. This approach is ugly and will need to be manually written into each onSaveInstanceState(), but the FragmentManager will automatically clean itself up once its activity lifecycle has ended. This allows me to avoid using retained fragments that are associated with views, and only use a retained fragment in my headless data holding instance. I do not mind the calls to onSaveInstanceState() all too much, as the lifecycle should be handled entirely by the view anyway, and Android already provides us this call to do so. While this does prevent saving data in any Child sub-Fragments, you should not be using those anyway.
It is not a good approach. But it lets me at least use the full lifecycle of the Activity/Fragment while not having to worry about preserving the Presenters I need. I find it better than an in-memory cache because it is automatically associated and destroyed with its Activity, where as you would have to manually manage an in-memory singleton cache yourself.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Monday, May 9, 2016
Thursday, May 5, 2016
For SEO Purposes
Target.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Realistically Open Source and Android Permissions
I hope it's no secret that all of my applications are open source.
At least, all the ones that I actively maintain here.
The source, in its entirety save for perhaps some API keys is readable. Every single git commit (except that time I messed up) are visible for your viewing pleasure.
Still there are concerns that the code may not be as free as one believes. If you download the APK on your phone or grab a program from the AUR, you can sometimes feel unsure if the code you are running was the same as the sources you saw.
In the case of stuff from the AUR, they are all bash (really sh) scripts. Read them (help me fix them), you will notice they are in fact - the same as the sources on GitHub.
In the case of your Android APKs the process is a bit more involved. Some of the applications are still obfuscated by ProGuard. This is because I have not gotten around to updating them with the fixed ProGuard configuration that prevents obfuscation.
You may however, find the APKs decompiled Java code difficult to read or sometimes even be unable to decompile the class files. This is because I am not the perfect programmer, so I still leave on the default ProGuard code optimizations.
As a result, you get blocks of optimized code that do not look very nice. While this may concern some users, rest assured that none of the pyamsoft Android applications are "out to get you" or monitor your usage. In fact, the most recently update applications do not even contact the Internet at all.
Lets face the truth here, we all hate Android permissions. So many applications, like the infamous free Flashlight and Calculator applications, ask for so many different permissions like the Internet, your Contacts, sometimes even your Microphone. So many applications do not need these permissions yet they request or require them at runtime anyway.
Except where essential for functionality, I do not. I never will.
PadLock requires zero permissions.
ZapTorch requires the Camera only to access the torch (on devices below Marshmallow)
Home Button requires Zero permissions.
In the future, Power Manager will require zero. SoftGlow will not even require the Draw over all windows permission (though it will be optional).
All of these applications are either open source, or will be.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
At least, all the ones that I actively maintain here.
The source, in its entirety save for perhaps some API keys is readable. Every single git commit (except that time I messed up) are visible for your viewing pleasure.
Still there are concerns that the code may not be as free as one believes. If you download the APK on your phone or grab a program from the AUR, you can sometimes feel unsure if the code you are running was the same as the sources you saw.
In the case of stuff from the AUR, they are all bash (really sh) scripts. Read them (help me fix them), you will notice they are in fact - the same as the sources on GitHub.
In the case of your Android APKs the process is a bit more involved. Some of the applications are still obfuscated by ProGuard. This is because I have not gotten around to updating them with the fixed ProGuard configuration that prevents obfuscation.
You may however, find the APKs decompiled Java code difficult to read or sometimes even be unable to decompile the class files. This is because I am not the perfect programmer, so I still leave on the default ProGuard code optimizations.
As a result, you get blocks of optimized code that do not look very nice. While this may concern some users, rest assured that none of the pyamsoft Android applications are "out to get you" or monitor your usage. In fact, the most recently update applications do not even contact the Internet at all.
Lets face the truth here, we all hate Android permissions. So many applications, like the infamous free Flashlight and Calculator applications, ask for so many different permissions like the Internet, your Contacts, sometimes even your Microphone. So many applications do not need these permissions yet they request or require them at runtime anyway.
Except where essential for functionality, I do not. I never will.
PadLock requires zero permissions.
ZapTorch requires the Camera only to access the torch (on devices below Marshmallow)
Home Button requires Zero permissions.
In the future, Power Manager will require zero. SoftGlow will not even require the Draw over all windows permission (though it will be optional).
All of these applications are either open source, or will be.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Fabric annoyances
For a side project I was tasked with integrating services from the Twitter owned Fabric.io kits into the Android application.
This proved to be very annoying.
Fabric is (to my understanding) designed so that once you provide your API key/ Twitter secret, your application will use the Internet permission to contact the Fabric servers and let the backend know that your organization has created a new application that uses Fabric services.
This is, in theory, very easy. And in fact, the first time around it was. Add keys, build, run, bing bam done deal-o.
The problem arose when migrating an application from one Fabric "organization" to another Fabric "organization." For single developers like myself, an organization is Fabric is akin to "your account."
All one has to do to migrate over was to change API keys, and rebuild. Magically things should work.
Realistically things did not, at least not at first. And for that I blame myself.
I develop using Android Studio inside of a firejail sandbox for various paranoid reasons. This sandbox is the only piece of my machine which is set up with the Java and Android SDKs, and is (hopefully) secured. It runs in a separate IPC namespace, and a separate network namespace with no access to the root account or any privilege beyond running the Java compiler and the Android emulators which are not given network access, except across a single network bridge.
But Fabric, for whatever reason, does not like this.
So fine, un-sandbox the Android Studio instance JUST to register a new application onto Fabric.
Not quite.
My development device is using NetGuard, the beautiful no-root firewall (and ad blocker) which creates a transparent VPN and blah blah on my device.
Fabric does not like this either.
After a couple minutes of Googling and fiddling around with networks on my machine and device, Fabric springs to life and complains about API keys.
Wonderful! Now its no longer a "generic" issue, its a Fabric issue. Those can be fixed with Fabric documentation and sweat and blood.
In summary, Crashlytics and Digits do not like network proxies.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
This proved to be very annoying.
Fabric is (to my understanding) designed so that once you provide your API key/ Twitter secret, your application will use the Internet permission to contact the Fabric servers and let the backend know that your organization has created a new application that uses Fabric services.
This is, in theory, very easy. And in fact, the first time around it was. Add keys, build, run, bing bam done deal-o.
The problem arose when migrating an application from one Fabric "organization" to another Fabric "organization." For single developers like myself, an organization is Fabric is akin to "your account."
All one has to do to migrate over was to change API keys, and rebuild. Magically things should work.
Realistically things did not, at least not at first. And for that I blame myself.
I develop using Android Studio inside of a firejail sandbox for various paranoid reasons. This sandbox is the only piece of my machine which is set up with the Java and Android SDKs, and is (hopefully) secured. It runs in a separate IPC namespace, and a separate network namespace with no access to the root account or any privilege beyond running the Java compiler and the Android emulators which are not given network access, except across a single network bridge.
But Fabric, for whatever reason, does not like this.
So fine, un-sandbox the Android Studio instance JUST to register a new application onto Fabric.
Not quite.
My development device is using NetGuard, the beautiful no-root firewall (and ad blocker) which creates a transparent VPN and blah blah on my device.
Fabric does not like this either.
After a couple minutes of Googling and fiddling around with networks on my machine and device, Fabric springs to life and complains about API keys.
Wonderful! Now its no longer a "generic" issue, its a Fabric issue. Those can be fixed with Fabric documentation and sweat and blood.
In summary, Crashlytics and Digits do not like network proxies.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
HTTPS redirect
I have enabled HTTPS redirect on the blog for teh m0ar securiTz.
Please let me know if you have issues accessing the blog.
Or rather, tell Google.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Please let me know if you have issues accessing the blog.
Or rather, tell Google.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
More locks
PadLock is seeing quick development as I pull ideas out of my head.
Currently it is designed around a number pad, which is a custom view I created using a grid of numbers in a linear layout. The number pad is limited, in that it only allows numeric passcodes. This is not the best, as we have support for any passcode which is a valid, non-null String. As such, in the next release, 1.1.0, I've taken the liberty of ripping out this number pad in exchange for the users system keyboard. Your existing PadLock passcodes will still work, needing no changes. Now though, you will be able to enter in alphanumeric passcodes with symbols and the whole shebang.
You are technically also able to leave the passcode field blank as a valid passcode. While this is not recommended, it is not my job to tell you how to use your device. Though I have flirted with the idea of passcode requirements in the past, they have proven to be too limiting and can in some cases reveal passcode schema. As such, they are not going to be in place for this release.
Additional improvements include faster UI response times as more code is being moved off of the main thread and being handled via the RX observable framework. One nice example is that all preference object accesses are done off of the main thread as a hard requirement. I am still looking to rewrite the UI to simple update when the backend DB storage updates for smoother connection to the database and better handling of changes than we have now.
Anyway, these changes can all be observed on the dev branch, which I hope to freeze into a beta-1.1.0 branch in the coming week.
ZapTorch has also been updated to use RX as its threading framework, as I just like it so much. I'm looking to replace the instance of AsyncTask loading the Camera with an RX call in the future. I am not pushing RX into the pydroid library as of yet as some of the projects, like Home Button, do not need the additional complexity of the RX framework.
Ramble over.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Currently it is designed around a number pad, which is a custom view I created using a grid of numbers in a linear layout. The number pad is limited, in that it only allows numeric passcodes. This is not the best, as we have support for any passcode which is a valid, non-null String. As such, in the next release, 1.1.0, I've taken the liberty of ripping out this number pad in exchange for the users system keyboard. Your existing PadLock passcodes will still work, needing no changes. Now though, you will be able to enter in alphanumeric passcodes with symbols and the whole shebang.
You are technically also able to leave the passcode field blank as a valid passcode. While this is not recommended, it is not my job to tell you how to use your device. Though I have flirted with the idea of passcode requirements in the past, they have proven to be too limiting and can in some cases reveal passcode schema. As such, they are not going to be in place for this release.
Additional improvements include faster UI response times as more code is being moved off of the main thread and being handled via the RX observable framework. One nice example is that all preference object accesses are done off of the main thread as a hard requirement. I am still looking to rewrite the UI to simple update when the backend DB storage updates for smoother connection to the database and better handling of changes than we have now.
Anyway, these changes can all be observed on the dev branch, which I hope to freeze into a beta-1.1.0 branch in the coming week.
ZapTorch has also been updated to use RX as its threading framework, as I just like it so much. I'm looking to replace the instance of AsyncTask loading the Camera with an RX call in the future. I am not pushing RX into the pydroid library as of yet as some of the projects, like Home Button, do not need the additional complexity of the RX framework.
Ramble over.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Monday, May 2, 2016
Lots of little patches
Lots of little patches today. PadLock, ZapTorch, and Home Button all got updated to work with a couple of new features.
None of them require Internet or declare Internet permissions anymore.
No ads in any of the applications.
Applications are now donation supported. Donations are handled via Android In-App Billing in the form of consumable items priced at one, two, five, and ten dollars.
If you visit the repositories for PyDroid, PadLock, ZapTorch, and Home Button, you will notice they went from something like 500 commits (in the case of PadLock) to only 10 or 20. This is unfortunately because an API key may have been uploaded to one or more of these repositories on accident, and thus saved in the Git history. While I cannot confirm that this was the case, this was the safest way for me to make sure that the repositories start clean.
As of this point, no sensitive information is ignored from any of these repositories, meaning the code you see on GitHub is the code I work on and the code that runs in your APK.
On an additional note, I have stopped obfuscating code in the APK files. This is for those who are hyper paranoid and want to make sure that the code running on the device is the same as the source on GitHub. I can assure you it is. Note that some ProGuard optimizations may make some of the class files unreadable via a decompiler.
I hope to once again look at Power Manager in the next couple of weeks and continue working on that application. There is a lot of crusty code in it that could use a refresher.
steam-wrapper was updated to fix a crash caused by new libgpg-error libraries shipped in the runtime. The latest version, 0.2.4, should allow one to launch Steam using the runtime on distros that are not Ubuntu 12.04.
More to come.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
None of them require Internet or declare Internet permissions anymore.
No ads in any of the applications.
Applications are now donation supported. Donations are handled via Android In-App Billing in the form of consumable items priced at one, two, five, and ten dollars.
If you visit the repositories for PyDroid, PadLock, ZapTorch, and Home Button, you will notice they went from something like 500 commits (in the case of PadLock) to only 10 or 20. This is unfortunately because an API key may have been uploaded to one or more of these repositories on accident, and thus saved in the Git history. While I cannot confirm that this was the case, this was the safest way for me to make sure that the repositories start clean.
As of this point, no sensitive information is ignored from any of these repositories, meaning the code you see on GitHub is the code I work on and the code that runs in your APK.
On an additional note, I have stopped obfuscating code in the APK files. This is for those who are hyper paranoid and want to make sure that the code running on the device is the same as the source on GitHub. I can assure you it is. Note that some ProGuard optimizations may make some of the class files unreadable via a decompiler.
I hope to once again look at Power Manager in the next couple of weeks and continue working on that application. There is a lot of crusty code in it that could use a refresher.
steam-wrapper was updated to fix a crash caused by new libgpg-error libraries shipped in the runtime. The latest version, 0.2.4, should allow one to launch Steam using the runtime on distros that are not Ubuntu 12.04.
More to come.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Tuesday, April 26, 2016
PadLock released
The first public release of PadLock just got pushed right now.
PadLock has been worked on tirelessly for the past couple of months. It was a learning experience for me to learn both RxJava, and more recently the Dagger (2) DI frameworks. It was a wild ride, and after a lot of rewriting and different ideas on implementation (like replacing SQL for Realm and then replacing Realm again for SQL), PadLock has finally seen its first release with nearly 500 commits to its name.
Perhaps the think I appreciate the most about this release is how much I have learned in coding it. PadLock attempts the MVP pattern using RxJava and Dagger2, and accomplishes its simple job as an application locker while requiring literally zero runtime permissions. It doesn't even use the Internet.
Now that it is released, the Master branch will stay at whatever the 1.0.1 code was. All new developments will take place in named branches, the results of which will be pushed into the 'dev' branch. I look forward to improving PadLock in the future with more features and better security.
Go out and try it!
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
PadLock has been worked on tirelessly for the past couple of months. It was a learning experience for me to learn both RxJava, and more recently the Dagger (2) DI frameworks. It was a wild ride, and after a lot of rewriting and different ideas on implementation (like replacing SQL for Realm and then replacing Realm again for SQL), PadLock has finally seen its first release with nearly 500 commits to its name.
Perhaps the think I appreciate the most about this release is how much I have learned in coding it. PadLock attempts the MVP pattern using RxJava and Dagger2, and accomplishes its simple job as an application locker while requiring literally zero runtime permissions. It doesn't even use the Internet.
Now that it is released, the Master branch will stay at whatever the 1.0.1 code was. All new developments will take place in named branches, the results of which will be pushed into the 'dev' branch. I look forward to improving PadLock in the future with more features and better security.
Go out and try it!
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Monday, April 11, 2016
pstate-more-frequent
pstate-frequency 3.1.0 is a tiny update to a tiny program.
Remember that old systemd service you had to enable for x86_enery_perf_policy support? Well remember no more.
pstate-frequency now comes with a flag -x | --x86 which sets the policy to whatever you ask, how neat. The flag is set by default when a power plan is requested, and can be overridden to any other policy, including a special 'none' option argument which tells pstate-frequency to not touch the x86_energy_perf_plan setting. And if you do not have the x86_energy_perf_policy program installed, pstate-frequency will just skip over it.
This should allow you to remove the systemd service for x86_energy_perf_policy and just use the pstate-frequency services. In fact, I've taken the liberty to do it for you already.
Two posts in one day, a new record perhaps.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Remember that old systemd service you had to enable for x86_enery_perf_policy support? Well remember no more.
pstate-frequency now comes with a flag -x | --x86 which sets the policy to whatever you ask, how neat. The flag is set by default when a power plan is requested, and can be overridden to any other policy, including a special 'none' option argument which tells pstate-frequency to not touch the x86_energy_perf_plan setting. And if you do not have the x86_energy_perf_policy program installed, pstate-frequency will just skip over it.
This should allow you to remove the systemd service for x86_energy_perf_policy and just use the pstate-frequency services. In fact, I've taken the liberty to do it for you already.
Two posts in one day, a new record perhaps.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
ZapTorch
I know.
What kind of name is that?
I'm bad at names, sorry.
Anywho, ZapTorch (name pending) is a simple application I created in the last five days. Born out of annoyance, this application is very simple. It only does one thing.
You click click.
It turns on the flashlight.
I know. Amazing right.
Turns out its more useful than you might think at first. Give it a go and you'll see.
Some caveats though:
- Due to the way Android handles applications listening for keypresses, ZapTorch will only respond to a double press of a button while the screen is On.
- ZapTorch will only listen for the Volume Down key. Press it twice in a short (configurable) time window and you'll get light.
- In order to capture key events from everywhere, ZapTorch needs an accessibility service.
However, don't be alarmed at all of these caveats. ZapTorch does not talk to the Internet at all, it lacks the permission on Android to even do so. It only monitors for the Volume Down key.
woohoo.
Padlock coming soon (tm).
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
What kind of name is that?
I'm bad at names, sorry.
Anywho, ZapTorch (name pending) is a simple application I created in the last five days. Born out of annoyance, this application is very simple. It only does one thing.
You click click.
It turns on the flashlight.
I know. Amazing right.
Turns out its more useful than you might think at first. Give it a go and you'll see.
Some caveats though:
- Due to the way Android handles applications listening for keypresses, ZapTorch will only respond to a double press of a button while the screen is On.
- ZapTorch will only listen for the Volume Down key. Press it twice in a short (configurable) time window and you'll get light.
- In order to capture key events from everywhere, ZapTorch needs an accessibility service.
However, don't be alarmed at all of these caveats. ZapTorch does not talk to the Internet at all, it lacks the permission on Android to even do so. It only monitors for the Volume Down key.
woohoo.
Padlock coming soon (tm).
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================
Subscribe to:
Posts (Atom)