Hope you all enjoyed the weekend.
PadLock was updated to 1.3.1 which removes the tab view pager interface in favor of just separate screens per fragment. This should give more vertical screen real-estate when using the application in landscape modes.
Also cleaned up a lot of the application with those annotations I love so much, hopefully when things crash I can expect them to now.
ZapTorch also was updated to 1.1.2 which allows for switching which Camera API controls the flashlight at runtime. It will also be nicer about displaying error dialogs regarding permissions or just plain errors.
SoftGlow rewrite for version 3.0.0 has begun, but no real progress has been made on it other than some cleanup and updating dependencies. I hope to get more serious work done on it later in the week.
Brief today. More later.
========================
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, May 31, 2016
Wednesday, May 25, 2016
Firejailing Steam
firejail is an application sandbox that uses technologies I don't understand to make using my computer more difficult. It also provides a basic security sandbox and helps protect me from malicious applications.
Remember that by default Linux is rather secure, but depending on the user's needs there may be situations where more fine grained control is desired. Firejail allows a novice user (like myself) to apply all of these existing security technologies already built into the kernel to give them a safety net should an application go rogue. It does so via profiles, which control how much - or how little - additional securities should be applied to an application.
There is a steam.profile, which ships with the firejail application as a supported profile. For 90% of games, this profile works fine, but there is a single instance that I have observed so far where applying this steam.profile crashed the game. The game in question, is Unturned.
I am not placing blame on either developer here, I am just stating what I noticed and what worked for me.
Remember that by default Linux is rather secure, but depending on the user's needs there may be situations where more fine grained control is desired. Firejail allows a novice user (like myself) to apply all of these existing security technologies already built into the kernel to give them a safety net should an application go rogue. It does so via profiles, which control how much - or how little - additional securities should be applied to an application.
There is a steam.profile, which ships with the firejail application as a supported profile. For 90% of games, this profile works fine, but there is a single instance that I have observed so far where applying this steam.profile crashed the game. The game in question, is Unturned.
I am not placing blame on either developer here, I am just stating what I noticed and what worked for me.
Unturned crashes for whatever reason when the default steam.profile is applied via firejail. The crash can be worked around by ignoring the protocol line in the steam.profile file, which limits the application to using only the Unix socket protocol, and IPv4 IPv6 protocols. Unturned apparently needs something more, and even adding all of the protocols available into the steam.profile did not fix the crash. But, by ignoring the protocol line by passing the --ignore option when running firejail, Unturned launches fine. Beautiful.
Go grow a tomato farm and kill some zombers you. It's free.
On an unrelated Linux steam note, the microphone in CS:GO just does not work. The game also hard crashes if you try to load a map using changelevel <map> instead of map <map> in the console. Valve plz fix.
========================
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
=========================
$ firejail --ignore=protocol steam On an unrelated Linux steam note, the microphone in CS:GO just does not work. The game also hard crashes if you try to load a map using changelevel <map> instead of map <map> in the console. Valve plz fix.
========================
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
=========================
AsyncTasks and You
Let's talk about threading (again), and about AsyncTasks. I am not going to explain them, but rather assume that you are an Android developer who has just stumbled across this class in the framework and are trying to use them to do all the things.
As with all parts of the framework, you must always understand where it ties into the lifecycle. So first, let's leak some memory (prepare for some handwritten, from memory code).
Alright, so this leaks. If the instance of MyActivity is destroyed, the AsyncTask does not stop doing its background task. The AsyncTask holds an implicit reference to the MyActivity context, which leaks the entire activity. Blah blah, all things you've heard before.
You've also probably heard to avoid AsyncTask because they are bad and all that other fun stuff too. Well, sometimes you can't just use something else, or ship with RxJava or anything nice like that. Sometimes, all you've got is the Android framework. So take a moment to learn about AsyncTasks.
One of the easiest things you can do is to never create anonymous, non-static AsnycTask instances. Instead, you can create a static inner class which extends AsyncTask, or create the anonymous AsyncTask in a static function. This will prevent the AsyncTask from capturing the implicit reference to your Activity and should plug the hole on a major source of AsyncTask memory leaks.
The other thing would be to add checks during any long running doInBackground() code to see if the AsyncTask isCancelled(). If it is, you can stop the background operation and the AsyncTask would be able to be cleaned up at that point. In order to make this worthwhile though you would need to hold a strong reference to the AsyncTask itself in your Activity and call cancel() on it during onDestroy(). It is more work, and this should generally only be used if you really need to reference something in your Activity itself like an ImageView, and it should always be used along with the advice above about static classes or functions.
Finally, if you are holding an ImageView for example in your AsyncTask so that you can modify it onPostExecute(), you should always try to not hold a strong reference to it. The ImageView will also be held by the Activity itself, so your AsyncTask can get away with holding a WeakReference to it. If you are holding a Context, see if you can hold the Application context instead of the Activity context.
Finally finally, remember that on modern Android, AsyncTasks are run one after the other. This means that there may be cases where your task leaks just because it is waiting for the other one to finish its long running operation. Sometimes you are able to apply a parallel executor to the AsyncTasks, sometimes you are not. There is no silver bullet for AsyncTasks, you must remember to test and verify that your AsyncTasks work as intended and do not leak any precious memory.
========================
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
=========================
As with all parts of the framework, you must always understand where it ties into the lifecycle. So first, let's leak some memory (prepare for some handwritten, from memory code).
public class MyActivity extends Activity {
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { while (true) { // Loop forever. } return null; } }.execute(); }}Alright, so this leaks. If the instance of MyActivity is destroyed, the AsyncTask does not stop doing its background task. The AsyncTask holds an implicit reference to the MyActivity context, which leaks the entire activity. Blah blah, all things you've heard before.
You've also probably heard to avoid AsyncTask because they are bad and all that other fun stuff too. Well, sometimes you can't just use something else, or ship with RxJava or anything nice like that. Sometimes, all you've got is the Android framework. So take a moment to learn about AsyncTasks.
One of the easiest things you can do is to never create anonymous, non-static AsnycTask instances. Instead, you can create a static inner class which extends AsyncTask, or create the anonymous AsyncTask in a static function. This will prevent the AsyncTask from capturing the implicit reference to your Activity and should plug the hole on a major source of AsyncTask memory leaks.
The other thing would be to add checks during any long running doInBackground() code to see if the AsyncTask isCancelled(). If it is, you can stop the background operation and the AsyncTask would be able to be cleaned up at that point. In order to make this worthwhile though you would need to hold a strong reference to the AsyncTask itself in your Activity and call cancel() on it during onDestroy(). It is more work, and this should generally only be used if you really need to reference something in your Activity itself like an ImageView, and it should always be used along with the advice above about static classes or functions.
Finally, if you are holding an ImageView for example in your AsyncTask so that you can modify it onPostExecute(), you should always try to not hold a strong reference to it. The ImageView will also be held by the Activity itself, so your AsyncTask can get away with holding a WeakReference to it. If you are holding a Context, see if you can hold the Application context instead of the Activity context.
Finally finally, remember that on modern Android, AsyncTasks are run one after the other. This means that there may be cases where your task leaks just because it is waiting for the other one to finish its long running operation. Sometimes you are able to apply a parallel executor to the AsyncTasks, sometimes you are not. There is no silver bullet for AsyncTasks, you must remember to test and verify that your AsyncTasks work as intended and do not leak any precious memory.
========================
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, May 24, 2016
Testing in Production
Ramble mode engage.
--
I like you guys.
You're like my own little slice of users who, at this point, don't really expect all too much out of my applications and things that I make. So its neat then, because when I release something that's really bad, I get to see how it all pans out. I get to test in production, basically. And you; you're all a part of my little group of testers.
In the coming months, here's what will be happening.
I will be (as previously announced) removing advertisements from everything. Everything I can update in time. I probably won't get around to working on Power Manager, I'm saying it now. It's the largest (oldest (ugliest) ) application I have so far, even though that isn't saying much, and I have invested so much time into it that I want to work on other projects at the moment. I do hope to address SoftGlow though (also as noted before). Sounds good? Good. Moving on.
I will be experimenting with the idea of prompting for reviews. Don't be afraid, let me explain.
Most people have opinions about the applications they use whether they are vocal about them or not. Most people are just too lazy to voice their opinion as a review because they cannot be tasked with going to the store page and writing it up. I will be looking to interact better with my audience by prompting them a single time when the application is freshly updated or installed, to rate the application on the Play Store.
Voice concerns. Report bugs. Say thanks. Insult my family. Whatever you want to do, that small paragraph of text is yours to do it in.
The rating prompt will be in the form of a single dialog. It will only show up once, it will not badger you for five stars. It will give you only two options, either rate the application on the Play Store, or don't. That's it. Easy peasy. In fact, so easy, I will be planning on putting it into the applications I can update in time. Consider this like the "Empire Strikes Back" only the Empire returns in the form of a non intrusive dialog prompt instead of a crummy advertisement, and the Empire in this case is, well, me. The developer giveth, and the developer taketh away.
Market research shows that just by simply prompting a user to give feedback, the amount of feedback grows exponentially. I am wondering if this is the case, even for my very very tiny community of users.
Sorry, testers. And since you are now an official pyamsoft tester, I guess some congratulations are in order.
So.
Congratulations, you're hired! You start tomorrow.
========================
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
=========================
--
I like you guys.
You're like my own little slice of users who, at this point, don't really expect all too much out of my applications and things that I make. So its neat then, because when I release something that's really bad, I get to see how it all pans out. I get to test in production, basically. And you; you're all a part of my little group of testers.
In the coming months, here's what will be happening.
I will be (as previously announced) removing advertisements from everything. Everything I can update in time. I probably won't get around to working on Power Manager, I'm saying it now. It's the largest (oldest (ugliest) ) application I have so far, even though that isn't saying much, and I have invested so much time into it that I want to work on other projects at the moment. I do hope to address SoftGlow though (also as noted before). Sounds good? Good. Moving on.
I will be experimenting with the idea of prompting for reviews. Don't be afraid, let me explain.
Most people have opinions about the applications they use whether they are vocal about them or not. Most people are just too lazy to voice their opinion as a review because they cannot be tasked with going to the store page and writing it up. I will be looking to interact better with my audience by prompting them a single time when the application is freshly updated or installed, to rate the application on the Play Store.
Voice concerns. Report bugs. Say thanks. Insult my family. Whatever you want to do, that small paragraph of text is yours to do it in.
The rating prompt will be in the form of a single dialog. It will only show up once, it will not badger you for five stars. It will give you only two options, either rate the application on the Play Store, or don't. That's it. Easy peasy. In fact, so easy, I will be planning on putting it into the applications I can update in time. Consider this like the "Empire Strikes Back" only the Empire returns in the form of a non intrusive dialog prompt instead of a crummy advertisement, and the Empire in this case is, well, me. The developer giveth, and the developer taketh away.
Market research shows that just by simply prompting a user to give feedback, the amount of feedback grows exponentially. I am wondering if this is the case, even for my very very tiny community of users.
Sorry, testers. And since you are now an official pyamsoft tester, I guess some congratulations are in order.
So.
Congratulations, you're hired! You start tomorrow.
========================
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 Up
Long time no post.
pstate-frequency was updated to version 3.3.3 (.3.3.3.3.3.3) which brings support (again) for acpi-cpufreq. It wasn't that hard to support the older driver, although I did run into some bugs from releasing without adequate testing, but they should hopefully be fixed now. If there are bugs, or something doesn't quite work the way you expect, file a GitHub issue.
steam-wrapper was updated to version 0.2.6, which brings some new behavior. By default it will not remove any of the outdated steam runtime libraries, but rather will override the LD_PRELOAD path to point to the newer libraries instead. The older destructive functionality still exists by passing the -d | --delete-stale flag to steam-wrapper if that's more your thing. The linking of the flash 32 bit library will be removed in the next version, user be warned.
update-hosts got updated (haha.) to a new version whose number escapes me at the moment, but it adds in hosts file sources from the disconnect project as well as a new list from the malwaredomains tracking site, the zeus project, and a ransomware tracker. So hopefully more things will be caught. That being said, I don't want to block too many things, as this may end up breaking legitimate sites as well. I have tried to maintain the whitelist to mirror the uBlock Origin Unbreak list, but seeing as we are dealing with a very binary all-or-nothing style of filtering hosts, it is obviously not as robust. It is also updated by hand, meaning I will miss things along the way. Open a GitHub issue if you see anything that I have missed.
PadLock will get a small update that filters out all window events for only those that come from Activity instances. This should clean up the actual LockService code and hopefully make locking more reliable. I will also be adding an option (off by default) that will check for a lock entry every time the activity class changes. This is to combat a potential security issue where, if the main entry point of the Application (usually launcher activity) is left unlocked, then the entire application is potentially view-able as long as the currently observed package does not change. Check the source, while I have not actually tried to produce the bug, it is theoretically possible. The reason that the option is left off by default is due to the fact that when the application is "properly" locked, causing a new lock request on each activity change only makes things more annoying.
Finally work has begun on re-working basically all of SoftGlow as I am curious to see how it will perform in a more modern Android environment. Of course, with the announced changes to how background services are being restricted in the future Android versions, I will need to go back to the drawing board regarding how the application actually works.
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
=========================
pstate-frequency was updated to version 3.3.3 (.3.3.3.3.3.3) which brings support (again) for acpi-cpufreq. It wasn't that hard to support the older driver, although I did run into some bugs from releasing without adequate testing, but they should hopefully be fixed now. If there are bugs, or something doesn't quite work the way you expect, file a GitHub issue.
steam-wrapper was updated to version 0.2.6, which brings some new behavior. By default it will not remove any of the outdated steam runtime libraries, but rather will override the LD_PRELOAD path to point to the newer libraries instead. The older destructive functionality still exists by passing the -d | --delete-stale flag to steam-wrapper if that's more your thing. The linking of the flash 32 bit library will be removed in the next version, user be warned.
update-hosts got updated (haha.) to a new version whose number escapes me at the moment, but it adds in hosts file sources from the disconnect project as well as a new list from the malwaredomains tracking site, the zeus project, and a ransomware tracker. So hopefully more things will be caught. That being said, I don't want to block too many things, as this may end up breaking legitimate sites as well. I have tried to maintain the whitelist to mirror the uBlock Origin Unbreak list, but seeing as we are dealing with a very binary all-or-nothing style of filtering hosts, it is obviously not as robust. It is also updated by hand, meaning I will miss things along the way. Open a GitHub issue if you see anything that I have missed.
PadLock will get a small update that filters out all window events for only those that come from Activity instances. This should clean up the actual LockService code and hopefully make locking more reliable. I will also be adding an option (off by default) that will check for a lock entry every time the activity class changes. This is to combat a potential security issue where, if the main entry point of the Application (usually launcher activity) is left unlocked, then the entire application is potentially view-able as long as the currently observed package does not change. Check the source, while I have not actually tried to produce the bug, it is theoretically possible. The reason that the option is left off by default is due to the fact that when the application is "properly" locked, causing a new lock request on each activity change only makes things more annoying.
Finally work has begun on re-working basically all of SoftGlow as I am curious to see how it will perform in a more modern Android environment. Of course, with the announced changes to how background services are being restricted in the future Android versions, I will need to go back to the drawing board regarding how the application actually works.
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, May 17, 2016
UI Design in Crowded Applications
Mousewait.
It's an unofficial Disneyland application which seeks to simplify navigating the park with a single do-it-all style application. Its got wait times and scheduling and bathroom locations and, heck, even quizzes to kill time while you're waiting in line for the bathroom break that you scheduled at 3:30.
It's also, really, really cluttered, and overflowing with information.
Look at all dem buttons. Yes this is on iOS, but on Android the situation really isn't any better.
Admittedly, MouseWait sees this kind of interface as convenient, a one-handed mode of operation. While certainly debatable, there is no argument about it that MouseWait presents a lot of information. This information is, in my opinion, poorly organized into these radio button categories in this television remote like interface.
If one were to try and clean up the interface without changing much of the actual design patterns around it, I would do so first by replacing these buttons with Card like views. The cards could be re-arranged so that the things I view more important can go on top for easy access. Similarly, the things I view as not important at all can be dismissed into an archive of sorts so that they do not clutter up the main view.
If one were to go even deeper, reorganizing the application into a tabbed view-pager like interface can also provide some benefits. Think about the Google Play store, and the massive amount of information that it presents. It separates this information into distinct categories, which it then presents individually per tab. MouseWait could do with a system of categorization around common themes of its interface.
For example, the tabs for Disneyland and California Adventure wait times could be condensed into one view page centered around Wait Times that is split into two halves. Each half can then be dedicated to either Disneyland or California wait times.
Similarly, the Find Food and Find Restrooms and Find Events nearby you buttons could all be condensed into a Nearby page with some kind of similar structure.
Settings would be moved into its own category in a menu button, as the Settings control how the application itself works and does not necessarily affect the park experience.
Yes this would ultimately amount to more clicks, more swipes, and more taps, but it allows the user to break down each section of MouseWait's presented information into concise groupings. Users interested in wait times will go to the Wait Time tab and then work entirely in there until they are done focusing on wait times. Users seeking nearby refreshment can go to the nearby tab and work from there. It is very important for applications which present a large amount of information to break it down into small, easily processed pieces so that a user will not become more confused by trying to use the application.
To keep the theme of a "do-it-all" kind of application, the default tab that the application opens to can serve as a dashboard like interface, where the user's favorites and most commonly visited actions can be presented on the page. This will allow the users who want this fine grained customization to place wait times on the dashboard next to their nearby food locations, and can make the app feel more personalized and therefore create more of an emotional attachment for the user.
Now I am not the developer behind the MouseWait application nor do I know what his or her goals for the application may be. Admittedly I am not a very regular user of the application either, but perhaps if I found the interface less confusing I would be open to using it more.
========================
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
=========================
It's an unofficial Disneyland application which seeks to simplify navigating the park with a single do-it-all style application. Its got wait times and scheduling and bathroom locations and, heck, even quizzes to kill time while you're waiting in line for the bathroom break that you scheduled at 3:30.
It's also, really, really cluttered, and overflowing with information.
Look at all dem buttons. Yes this is on iOS, but on Android the situation really isn't any better.
Admittedly, MouseWait sees this kind of interface as convenient, a one-handed mode of operation. While certainly debatable, there is no argument about it that MouseWait presents a lot of information. This information is, in my opinion, poorly organized into these radio button categories in this television remote like interface.
If one were to try and clean up the interface without changing much of the actual design patterns around it, I would do so first by replacing these buttons with Card like views. The cards could be re-arranged so that the things I view more important can go on top for easy access. Similarly, the things I view as not important at all can be dismissed into an archive of sorts so that they do not clutter up the main view.
If one were to go even deeper, reorganizing the application into a tabbed view-pager like interface can also provide some benefits. Think about the Google Play store, and the massive amount of information that it presents. It separates this information into distinct categories, which it then presents individually per tab. MouseWait could do with a system of categorization around common themes of its interface.
For example, the tabs for Disneyland and California Adventure wait times could be condensed into one view page centered around Wait Times that is split into two halves. Each half can then be dedicated to either Disneyland or California wait times.
Similarly, the Find Food and Find Restrooms and Find Events nearby you buttons could all be condensed into a Nearby page with some kind of similar structure.
Settings would be moved into its own category in a menu button, as the Settings control how the application itself works and does not necessarily affect the park experience.
Yes this would ultimately amount to more clicks, more swipes, and more taps, but it allows the user to break down each section of MouseWait's presented information into concise groupings. Users interested in wait times will go to the Wait Time tab and then work entirely in there until they are done focusing on wait times. Users seeking nearby refreshment can go to the nearby tab and work from there. It is very important for applications which present a large amount of information to break it down into small, easily processed pieces so that a user will not become more confused by trying to use the application.
To keep the theme of a "do-it-all" kind of application, the default tab that the application opens to can serve as a dashboard like interface, where the user's favorites and most commonly visited actions can be presented on the page. This will allow the users who want this fine grained customization to place wait times on the dashboard next to their nearby food locations, and can make the app feel more personalized and therefore create more of an emotional attachment for the user.
Now I am not the developer behind the MouseWait application nor do I know what his or her goals for the application may be. Admittedly I am not a very regular user of the application either, but perhaps if I found the interface less confusing I would be open to using it more.
========================
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
=========================
Expressing Intent in Annotations
So lets talk Java Annotations for a bit. Specifically how they can apply to Android.
Annotations were added waaayy back when, something like Java 1.5 in 2004. You probably have noticed them strewn about your code already in the form of @Override in front of some of your functions.
Annotations are useful and neat and are relatively lightweight. While not necessary, they can save you headaches down the line when you are designing a large application or designing with a team. Many popular libraries rely on powerful Java Annotations to do things like dependency injection and mocking for tests, and so some developers seem to view annotations as just another way to declare things in Java.
While these annotation based libraries are very useful, I've found one commonly overlooked thing about annotations is the ability to use them to check for basic code mistakes and simplify usage of various functions around the project.
Lets focus for a bit on three annotations included in the Android support library, @NonNull, @Nullable, and @CheckResult.
@NonNull declares that the variable annotated with it should not be null. This would allow you to remove checks in your code that would check for the existence of the object, at least in the scope that it is referenced as @NonNull. It will throw up a lint warning if a null check is performed on a @NonNull variable.
@Nullable does the opposite of @NonNull, declaring that the annotated variable can be null, and will give out a lint warning if its usage is not guarded.
Note that both @NonNull and @Nullable do not throw up any compile time errors if the annotation contract should be violated. This means it is possible for you to pass a null argument into a @NonNull field, but you will get lint warnings when you attempt to do so. Similarly, even though you pass in an argument that is @NonNull, if the actual function you are passing that argument to specifies it as @Nullable, you will need to guard its access anyway. These annotations do not protect you from stupidity or bad programming practices, but they can make it easier to detect potential bugs in the code.
@CheckResult is slightly different in that it can show a lint error if the annotation contract is not respected. @CheckResult should only be applied to functions, and it will cause lint to throw an error if the return value of that function is not used in some way. It can be very useful in distinguishing between functions that return a value and those that do not. In many cases unless you are constructing a public API, my personal preference is to annotate any function that does not return void with @CheckResult.
There are many other useful annotations provided just by the Android support library. Take a peek at them here.
========================
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
=========================
Annotations were added waaayy back when, something like Java 1.5 in 2004. You probably have noticed them strewn about your code already in the form of @Override in front of some of your functions.
Annotations are useful and neat and are relatively lightweight. While not necessary, they can save you headaches down the line when you are designing a large application or designing with a team. Many popular libraries rely on powerful Java Annotations to do things like dependency injection and mocking for tests, and so some developers seem to view annotations as just another way to declare things in Java.
While these annotation based libraries are very useful, I've found one commonly overlooked thing about annotations is the ability to use them to check for basic code mistakes and simplify usage of various functions around the project.
Lets focus for a bit on three annotations included in the Android support library, @NonNull, @Nullable, and @CheckResult.
@NonNull declares that the variable annotated with it should not be null. This would allow you to remove checks in your code that would check for the existence of the object, at least in the scope that it is referenced as @NonNull. It will throw up a lint warning if a null check is performed on a @NonNull variable.
@Nullable does the opposite of @NonNull, declaring that the annotated variable can be null, and will give out a lint warning if its usage is not guarded.
Note that both @NonNull and @Nullable do not throw up any compile time errors if the annotation contract should be violated. This means it is possible for you to pass a null argument into a @NonNull field, but you will get lint warnings when you attempt to do so. Similarly, even though you pass in an argument that is @NonNull, if the actual function you are passing that argument to specifies it as @Nullable, you will need to guard its access anyway. These annotations do not protect you from stupidity or bad programming practices, but they can make it easier to detect potential bugs in the code.
@CheckResult is slightly different in that it can show a lint error if the annotation contract is not respected. @CheckResult should only be applied to functions, and it will cause lint to throw an error if the return value of that function is not used in some way. It can be very useful in distinguishing between functions that return a value and those that do not. In many cases unless you are constructing a public API, my personal preference is to annotate any function that does not return void with @CheckResult.
There are many other useful annotations provided just by the Android support library. Take a peek at them here.
========================
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 16, 2016
Getting Started with Android
Last one for today, unless I get bored.
I'm currently trying to teach (show) a colleague how to get started programming for Android. Let me preface this by saying that I do not claim to be a good or even a decent Android programmer, but I at least have a grasp on the basics in my opinion.
Anyway.
Android is hard. Not just in the same sense that, well, programming is hard. But Android is hard mainly because there is no simple answer to the "how do I do this?" question. Especially for a beginner.
My colleague, whom I will simply refer to as 'he' or 'him' from now on, is running into many a road block as he attempts to learn the ins and outs of Android. He barely knows Java. He's never worked with Android before, but is 'curious.' Normally, one would wonder why I would be wasting my time trying to teach someone to, essentially, code Java from the ground up and then attach Android knowledge onto it as well. My answer to that is that I see in him what I saw in myself when I first started. I had a will to learn and a hope to improve. I would find it extremely disheartening to be turned down before I had even began.
But where to begin?
First, you need to know Java. Luckily, Java has been around for a long time, and can be picked up with a basic understanding of the ideas of Classes and Object Orientated Programming. But once you know basic Java, that's where the real fun begins.
There is no disagreement around the fact that if you want to learn Android programming, you must understand the Android Activity. The Activity is, arguably, the single most important piece of any Android application as that it what the user will in many cases actually interact with. But the Activity is big, and has many additions that are sometimes used and sometimes not. And most folks don't even use the plain Activity anymore -- Oh sorry, I meant to link this one. If a new developer were to jump into the Android Activity and try his luck at creating even a super simple application, he may not always know where to start.
Android's default project layout gives a MainActivity java file and a couple of activity related XML files. It also imports a dependency library, appcompat, which imports with it another library, support. It also manages these dependencies in Gradle.
That seems like an awful lot of work to make a single Activity which displays 'Hello World.' And it is. But this is the world that a new developer is introduced into. This confusing mess of build systems, dependencies, and Android support libraries that have almost effectively become a core part of app development.
One way to learn about a framework or a programming language is to make a To-Do list application in that language or using that Framework (this is a step that I did not do when starting out). To-do lists generally touch on a large amount of various concepts, like programming an interface and setting up a service to notify the user at given times. So my programmer padawan begins this by first creating an Activity. He doesn't know what he's going to really need yet, but its a good place to start.
We muck around for a bit with which Activity implementation he should use. I'm not going to start confusing him with various support libraries, so I just have him use the framework Activity class. Awesome. Now for his to-do list, he's going to need, well, a list, so he starts to spin up a ListView.
Normally, this is the part where I tell him that ListView has "kind of" been replaced by this new, cooler version, but I hold my tongue. He won't be able to truly appreciate how much easier things are until he suffers the view holder pattern firsthand. Then comes the first of what I can only assume will be many "Android WTF" questions.
"If Android documentation recommends the viewholder pattern, and everyone seems to use the viewholder pattern, why didn't they just make the ListView use it by default instead of me having to make it every time."
Good question, my son. Android likes choice and doesn't believe the developer should be tied to one way of doing things. But aside from that, I can't really say why. In fact, Android seems to have realized this too, hence the release of RecyclerView which revolves around the ViewHolder pattern. But its support lib appcompat only.
But anyway, back to our story. He's hacked out a ListView with a viewholder-y adapter and he's ready to rumble. A couple HLOC later and now he's gotten to a point where he wants to be able to save his to-do list items somewhere so that he can close the app and still have them. We talk about SharedPreferences for a bit, seems easy enough. He wants to know if he can save images into SharedPreferences also, but I tell him that's a topic for another day and a different tool.
He wants to have the todo list start when he starts his phone and ping him with all of his open tasks. All good, we chat about Broadcast Receivers and a bit about Toasts. Easy peasy. Everything is going swimmingly, so let's pause for a second.
It is both good and bad to learn about the Android framework in this way. I am there with him, so I can point out his mistakes and tell him about what classes and tools to use for the problems he is seeing. I can help explain to him why certain bits are how they are, and what has worked in my experience.
But if I wasn't there, I wonder how would he have gone about figuring out what to use to create this simple to-do. Sure, it would be easy to Google search the questions he had. But some answers may point him to things like SQL databases, or ORMS, and he doesn't quite need that yet. He may not know what term to search for, or how to describe his problem to the search engine. He would not know what to do because he would not even know if the class exists. Sure he could read the documentation, just like he could read the Android Studio TOS, but its going to take him down a path that, while he may learn a lot, may distract him from answering his original questions.
Of course, one can argue that in order to learn you must have an open mind and welcome new knowledge; That you should learn the "right" way, not be spoon fed the answers. I fully agree. But this is not the situation that we all face, and sometimes we lack the patience or the knowledge or the experience to approach problems in a well thought out manner.
What Ifs aside though, I was there and I did tell him. So he doesn't have to search. He types, and I talk and explain what he's doing and he nods in fake understanding. I know he doesn't understand fully, as how could anyone the first time they are exposed to so much information, but I'm hoping that he will read back the code he's produced and at least try to make heads or tails of it. I'm hoping that he will learn everything he can now, so that when he ventures into the world of the support libraries and their tools, and bugs, he will be ready. So that when he learns about Android and its major fragmentation across versions and vendors (Samsung) he'll be prepared. So that when he reads about MVP and how "everything you've done up to this point is wrong, god activities, blah blah" he'll be ready to go back and make things cleaner and nicer. So that when he begins using RxJava and other fancier Android toolkits that he will at least be able to approach his problems and think critically.
But first, he'll have to suffer. He'll have to design applications the wrong way to understand why the correct way is "better." He'll need to hand code his threading so that he can appreciate the ease of use that libraries bring. He'll need to learn a lot, while still keeping up with the massive changes that happen in the Android ecosystem almost every day. And once he has suffered, he will be ready.
For Android N to come along and change every way he thinks about Activities. For Android O to come along and break loaders again for another year.
I'm gonna go type.
========================
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
=========================
I'm currently trying to teach (show) a colleague how to get started programming for Android. Let me preface this by saying that I do not claim to be a good or even a decent Android programmer, but I at least have a grasp on the basics in my opinion.
Anyway.
Android is hard. Not just in the same sense that, well, programming is hard. But Android is hard mainly because there is no simple answer to the "how do I do this?" question. Especially for a beginner.
My colleague, whom I will simply refer to as 'he' or 'him' from now on, is running into many a road block as he attempts to learn the ins and outs of Android. He barely knows Java. He's never worked with Android before, but is 'curious.' Normally, one would wonder why I would be wasting my time trying to teach someone to, essentially, code Java from the ground up and then attach Android knowledge onto it as well. My answer to that is that I see in him what I saw in myself when I first started. I had a will to learn and a hope to improve. I would find it extremely disheartening to be turned down before I had even began.
But where to begin?
First, you need to know Java. Luckily, Java has been around for a long time, and can be picked up with a basic understanding of the ideas of Classes and Object Orientated Programming. But once you know basic Java, that's where the real fun begins.
There is no disagreement around the fact that if you want to learn Android programming, you must understand the Android Activity. The Activity is, arguably, the single most important piece of any Android application as that it what the user will in many cases actually interact with. But the Activity is big, and has many additions that are sometimes used and sometimes not. And most folks don't even use the plain Activity anymore -- Oh sorry, I meant to link this one. If a new developer were to jump into the Android Activity and try his luck at creating even a super simple application, he may not always know where to start.
Android's default project layout gives a MainActivity java file and a couple of activity related XML files. It also imports a dependency library, appcompat, which imports with it another library, support. It also manages these dependencies in Gradle.
That seems like an awful lot of work to make a single Activity which displays 'Hello World.' And it is. But this is the world that a new developer is introduced into. This confusing mess of build systems, dependencies, and Android support libraries that have almost effectively become a core part of app development.
One way to learn about a framework or a programming language is to make a To-Do list application in that language or using that Framework (this is a step that I did not do when starting out). To-do lists generally touch on a large amount of various concepts, like programming an interface and setting up a service to notify the user at given times. So my programmer padawan begins this by first creating an Activity. He doesn't know what he's going to really need yet, but its a good place to start.
We muck around for a bit with which Activity implementation he should use. I'm not going to start confusing him with various support libraries, so I just have him use the framework Activity class. Awesome. Now for his to-do list, he's going to need, well, a list, so he starts to spin up a ListView.
Normally, this is the part where I tell him that ListView has "kind of" been replaced by this new, cooler version, but I hold my tongue. He won't be able to truly appreciate how much easier things are until he suffers the view holder pattern firsthand. Then comes the first of what I can only assume will be many "Android WTF" questions.
"If Android documentation recommends the viewholder pattern, and everyone seems to use the viewholder pattern, why didn't they just make the ListView use it by default instead of me having to make it every time."
Good question, my son. Android likes choice and doesn't believe the developer should be tied to one way of doing things. But aside from that, I can't really say why. In fact, Android seems to have realized this too, hence the release of RecyclerView which revolves around the ViewHolder pattern. But its support lib appcompat only.
But anyway, back to our story. He's hacked out a ListView with a viewholder-y adapter and he's ready to rumble. A couple HLOC later and now he's gotten to a point where he wants to be able to save his to-do list items somewhere so that he can close the app and still have them. We talk about SharedPreferences for a bit, seems easy enough. He wants to know if he can save images into SharedPreferences also, but I tell him that's a topic for another day and a different tool.
He wants to have the todo list start when he starts his phone and ping him with all of his open tasks. All good, we chat about Broadcast Receivers and a bit about Toasts. Easy peasy. Everything is going swimmingly, so let's pause for a second.
It is both good and bad to learn about the Android framework in this way. I am there with him, so I can point out his mistakes and tell him about what classes and tools to use for the problems he is seeing. I can help explain to him why certain bits are how they are, and what has worked in my experience.
But if I wasn't there, I wonder how would he have gone about figuring out what to use to create this simple to-do. Sure, it would be easy to Google search the questions he had. But some answers may point him to things like SQL databases, or ORMS, and he doesn't quite need that yet. He may not know what term to search for, or how to describe his problem to the search engine. He would not know what to do because he would not even know if the class exists. Sure he could read the documentation, just like he could read the Android Studio TOS, but its going to take him down a path that, while he may learn a lot, may distract him from answering his original questions.
Of course, one can argue that in order to learn you must have an open mind and welcome new knowledge; That you should learn the "right" way, not be spoon fed the answers. I fully agree. But this is not the situation that we all face, and sometimes we lack the patience or the knowledge or the experience to approach problems in a well thought out manner.
What Ifs aside though, I was there and I did tell him. So he doesn't have to search. He types, and I talk and explain what he's doing and he nods in fake understanding. I know he doesn't understand fully, as how could anyone the first time they are exposed to so much information, but I'm hoping that he will read back the code he's produced and at least try to make heads or tails of it. I'm hoping that he will learn everything he can now, so that when he ventures into the world of the support libraries and their tools, and bugs, he will be ready. So that when he learns about Android and its major fragmentation across versions and vendors (Samsung) he'll be prepared. So that when he reads about MVP and how "everything you've done up to this point is wrong, god activities, blah blah" he'll be ready to go back and make things cleaner and nicer. So that when he begins using RxJava and other fancier Android toolkits that he will at least be able to approach his problems and think critically.
But first, he'll have to suffer. He'll have to design applications the wrong way to understand why the correct way is "better." He'll need to hand code his threading so that he can appreciate the ease of use that libraries bring. He'll need to learn a lot, while still keeping up with the massive changes that happen in the Android ecosystem almost every day. And once he has suffered, he will be ready.
For Android N to come along and change every way he thinks about Activities. For Android O to come along and break loaders again for another year.
I'm gonna go type.
========================
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
=========================
The Internet is a Strange Place
I'll never sometimes understand the Internet.
To date, one of the most popular posts so far in my fields of musings is this one.
Many people wonder about why the Internet seems to be filling up more and more each day with clickbait and other shady kinds of advertisement practices.
Perhaps it is because it is easier to produce than actual content. Perhaps it gives the best return for investment.
Perhaps it is because at the end of the day, this kind of content is all we really want.
And that's fine.
========================
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
=========================
To date, one of the most popular posts so far in my fields of musings is this one.
Many people wonder about why the Internet seems to be filling up more and more each day with clickbait and other shady kinds of advertisement practices.
Perhaps it is because it is easier to produce than actual content. Perhaps it gives the best return for investment.
Perhaps it is because at the end of the day, this kind of content is all we really want.
And that's fine.
========================
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
=========================
Whats in the Pipeline
PadLock update soon hopefully. Cleans up the logic for how and when the LockScreen is launched, should fix cases where the screen launches when it is not wanted, and similarly, should fix cases when it does not launch but it should.
Other than that, just some general code fixes and updates.
ZapTorch will be updated too to take advantage of newer libraries and hopefully cleaner code base.
What I would like to work on next will be revisiting SoftGlow. I would like to redesign the application effectively from the ground up. This means a couple of new things.
SoftGlow will be bumped to version 3, even though it had a very short version 2 lifespan. Instead of tinting the screen based on the time of day as most other overlay applications do, I want to make use of the newer Android light sensors APIs so that the screen will be tinted when the Light sensor detects a certain level of light or lack of light. In this way, even if it is something like 8 AM in the morning (which should mean the sun is up in most cases), if your device is in the dark as you stare at your phone from under your bedsheets, the screen will still be tinted.
The other thing I hope to address will be the requirement for using the System Overlay permission. I have tested as a proof of concept for creating an overlay that does not require this permission and it most cases it is feasible. Some users will run into issues where the lock screen is not tinted without the System Overlay permission, so this next release for SoftGlow will bring allow tinting of most screens with no permission, and enable the tinting of all screens when the draw overlays permission is granted.
The next release will also remove the Internet permission as it will not be required (no ads anymore) and will bring in its place instead Android In App Purchasing via the same means as the other updated pyamsoft applications.
Finally, I hope to revise SoftGlow to work with many of the same design principles that SoftGlow and ZapTorch have been created with. This means that I will try (to the best of my ability) to implement a clean MVP architecture and adhere to the idea of SOLID classes as much as possible. But of course, I'm only human.
Hopefully I will have more news in the future, but for now I should work on putting code on the page. Stay tuned.
EDIT: Fixed a typo. Sacrificed a french fry.
========================
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
=========================
Other than that, just some general code fixes and updates.
ZapTorch will be updated too to take advantage of newer libraries and hopefully cleaner code base.
What I would like to work on next will be revisiting SoftGlow. I would like to redesign the application effectively from the ground up. This means a couple of new things.
SoftGlow will be bumped to version 3, even though it had a very short version 2 lifespan. Instead of tinting the screen based on the time of day as most other overlay applications do, I want to make use of the newer Android light sensors APIs so that the screen will be tinted when the Light sensor detects a certain level of light or lack of light. In this way, even if it is something like 8 AM in the morning (which should mean the sun is up in most cases), if your device is in the dark as you stare at your phone from under your bedsheets, the screen will still be tinted.
The other thing I hope to address will be the requirement for using the System Overlay permission. I have tested as a proof of concept for creating an overlay that does not require this permission and it most cases it is feasible. Some users will run into issues where the lock screen is not tinted without the System Overlay permission, so this next release for SoftGlow will bring allow tinting of most screens with no permission, and enable the tinting of all screens when the draw overlays permission is granted.
The next release will also remove the Internet permission as it will not be required (no ads anymore) and will bring in its place instead Android In App Purchasing via the same means as the other updated pyamsoft applications.
Finally, I hope to revise SoftGlow to work with many of the same design principles that SoftGlow and ZapTorch have been created with. This means that I will try (to the best of my ability) to implement a clean MVP architecture and adhere to the idea of SOLID classes as much as possible. But of course, I'm only human.
Hopefully I will have more news in the future, but for now I should work on putting code on the page. Stay tuned.
EDIT: Fixed a typo. Sacrificed a french fry.
========================
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
=========================
Saturday, May 14, 2016
PadLock updated
An update to PadLock was pushed earlier today which brings its version to 1.1.1
This release cleans up the SQL table that holds the locked entries for the system and also fixes some potential crashes. Some code cleanups and a better way to handle updates from SQL to the Android main thread.
Expect to see an update in the Play Store in a few hours.
========================
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 release cleans up the SQL table that holds the locked entries for the system and also fixes some potential crashes. Some code cleanups and a better way to handle updates from SQL to the Android main thread.
Expect to see an update in the Play Store in a few hours.
========================
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
=========================
Friday, May 13, 2016
What I've learned
TL;Dr I have a lot to learn.
I like Android, no secret there.
I've been attempting to do things on Android for the past 3 years or so. I started knowing literally nothing, no Java, no XML, not even design or best practices or anything really.
I've been attempting to do things on Android for the past 3 years or so. I started knowing literally nothing, no Java, no XML, not even design or best practices or anything really.
I knew one academic quarter of Python. And I had some free time.
The first year I struggled wrapping my head around just plain Java and making layouts in XML. I felt like there was always so much about Android that I could never manage to learn it all.
In a way, I was right. There is so much in the Android SDK, even experienced developers will sometimes run across a feature they've never seen before. And this should come as no surprise, as there are many problems that an application can tackle and many ways to solve the same problem. My first year with Android was all about worrying if I would ever learn enough.
My second year was all about catching up on the things I had missed the first year around when I was getting Java and Android under my fingers. Basic things I had missed. Things like orientation change, context leaks, memory management, threading on Android. Layout efficiency and inflation was a topic I had recently discovered and it fascinated me. It was around this time I also began using Git, and scripting much of my build process in shell scripts. I felt like already I had come a long way, even if my Android applications themselves may have not shown much difference.
In my third year is when I feel like I truly began exploring the world of Android and Java. I learned about libraries and how useful they are. I learned about RxJava and the idea of applying functional programming concepts to an OOP language. I learned about MVP and what I should look for when designing my applications. I learned why Java and Android were ugly, and how many differences there were across devices and platform versions. I learned I had a lot of rewriting to do. I'm happy that I learned this all now, because if I had known about this any earlier I probably would have stopped Android. Any later I would have been too deep in bad habits to really make a change.
And there is still so much out there I just don't know. I don't know how it works or maybe I don't even know it exists. Case in point, I learned about the existence of RoboElectric about 2 days ago.
I'm not the best programmer, but I've found over the years that I don't have to be. Improving comes with time, as long as my drive to get better is still there. As long as I know there is more out there to learn. As long as Android continues to persevere as the open system that encourages improvement and change.
I'm always learning, always striving to get better. Always looking for new things to make.
give me money
========================
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
=========================
Wednesday, May 11, 2016
Disk Encryption on a crummy laptop
About 30 minutes ago I decided that I wanted to use full disk encryption on my Arch Linux installation. My setup would be something simple (I'm not looking for plausible deniability or protecting my information to any extreme degree). It would effectively look like this:
/dev/sda1 -> encrypted root partition (home, var, everything)
/dev/sdb1 -> un-encrypted boot partition
As a laptop user, I want things to be rather convenient, but I still want to maintain at least a basic level of encryption. My setup then is that the OS will be placed on a fully encrypted single partition as I'm too lazy to setup LVM or the like, and that partition will hold the LUKS header (so no plausible deniability of encryption) which will store a single password based LUKS key. The disk itself will not know how to boot.
The boot partition will be stored on a separate, un-encrypted USB stick. This stick will need to be plugged in each time the machine boots, and will also need to be present for any upgrades which deal with kernel images or the bootloader (GRUB in my case). By doing so, a person would need to have the physical USB stick as well as know the password (or execute some variety of an evil maid attack).
Would it make things safer? Not necessarily, but then again this is more of a learning experience than an actual data privacy guarantee.
The actual process was not that hard. The Arch Wiki has a page on dm-crypt setup for a very simple layout. One can follow all of the simple layout steps except that boot should be created on a separate USB stick instead of the internal hard disk. It will only take about 30 minutes to do from the beginning of the install to restoring all of my system information from Git repositories and re-downloaded packages (not accounting the time it may take to erase and encrypt the drive).
========================
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
=========================
/dev/sda1 -> encrypted root partition (home, var, everything)
/dev/sdb1 -> un-encrypted boot partition
As a laptop user, I want things to be rather convenient, but I still want to maintain at least a basic level of encryption. My setup then is that the OS will be placed on a fully encrypted single partition as I'm too lazy to setup LVM or the like, and that partition will hold the LUKS header (so no plausible deniability of encryption) which will store a single password based LUKS key. The disk itself will not know how to boot.
The boot partition will be stored on a separate, un-encrypted USB stick. This stick will need to be plugged in each time the machine boots, and will also need to be present for any upgrades which deal with kernel images or the bootloader (GRUB in my case). By doing so, a person would need to have the physical USB stick as well as know the password (or execute some variety of an evil maid attack).
Would it make things safer? Not necessarily, but then again this is more of a learning experience than an actual data privacy guarantee.
The actual process was not that hard. The Arch Wiki has a page on dm-crypt setup for a very simple layout. One can follow all of the simple layout steps except that boot should be created on a separate USB stick instead of the internal hard disk. It will only take about 30 minutes to do from the beginning of the install to restoring all of my system information from Git repositories and re-downloaded packages (not accounting the time it may take to erase and encrypt the drive).
========================
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, May 10, 2016
Shrinking Migrations
So this is just a small post regarding a recent operation I had to do regarding SQL database migrations.
PadLock version 1.1.0 (currently on the Play Store) had an SQL database with a schema looking something like this:
This would mean that entries in PadLock looked like this:
The displayName field was the exact same for every application in a package. For an application like Chrome or the Amazon Store, this could lead to hundreds of entries all storing the same value for the displayName field.
The displayName field existed only for one purpose, to populate the toolbar on the LockScreenActivity. Seems like a lot of work for something that can be loaded by the PackageManager as long as we have the package name.
So I wanted to go about removing the displayName field which would make the database cleaner and free up the space otherwise held by that TEXT entry. In order to do so, I needed to bump the database version and provide a migration.
SQLite on Android only provides a subset of the ALTER TABLE functionality. Effectively, it can only rename tables. There is no support for dropping individual columns, which is what I needed to do in this case.
The hacky solution then, was this.
While not too difficult in practice, this is admittedly a hacky work around to a limitation with SQLite, but appears to be the only nice way to get things done.
========================
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 version 1.1.0 (currently on the Play Store) had an SQL database with a schema looking something like this:
packageName TEXT,
activityName TEXT,
displayName TEXT,
lockCode TEXT,
lockUntilTime INTEGER,
ignoreUntilTime INTEGER,
systemApplication INTEGER As BOOLEAN
This would mean that entries in PadLock looked like this:
com.pyamsoft.padlock|com.pyamsoft.padlock.app.main.MainActivity|PadLock|NULL|0|0|0
com.pyamsoft.padlock|com.pyamsoft.padlock.app.lockscreen.LockScreenActivity|PadLock|NULL|0|0|0The displayName field was the exact same for every application in a package. For an application like Chrome or the Amazon Store, this could lead to hundreds of entries all storing the same value for the displayName field.
The displayName field existed only for one purpose, to populate the toolbar on the LockScreenActivity. Seems like a lot of work for something that can be loaded by the PackageManager as long as we have the package name.
So I wanted to go about removing the displayName field which would make the database cleaner and free up the space otherwise held by that TEXT entry. In order to do so, I needed to bump the database version and provide a migration.
SQLite on Android only provides a subset of the ALTER TABLE functionality. Effectively, it can only rename tables. There is no support for dropping individual columns, which is what I needed to do in this case.
The hacky solution then, was this.
ALTER the old table by naming it to a new name.
Copy the schema of the table and remove all of the columns that are being dropped.
Create a new table using the original table nameCopy over all of the needed information from the old table into the new one.
Delete the old table to free up the memory space.
While not too difficult in practice, this is admittedly a hacky work around to a limitation with SQLite, but appears to be the only nice way to get things done.
========================
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
Visiting Presenter State saving
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
=========================
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
=========================
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
=========================
Subscribe to:
Posts (Atom)