Tuesday, November 21, 2017

Accessibility Services and You

PadLock, Pasterino, and ZapTorch all rely on Accessibility Services to function.

Recently, the big G began sending take down notices for apps that are using Accessibility without targeting people with disabilities, and PadLock was flagged as not complying with the big G's terms of service.

As such, PadLock is being re-written to not use the Accessibility framework. While the behavior of the application should largely remain the same, the performance may suffer slightly and the app may be less reliable since it does not have access to the same powerful tools that it once did. As an unfortunate side effect, any users below Lollipop 5.1 (API 22) will be unable to use the updated version of the app. If you are stuck on an older version of Android such as KitKat or Lollipop, the final released update to PadLock will be version 2.3.3, and you will no longer receive any more updates to the application, as it is using an unsupported Accessibility service.

For the time being, it seems that Pasterino and ZapTorch are not being targeted, which is nice since for these applications there is literally no alternative to replace their functionalities.

Updates coming most likely 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
=========================

Monday, October 30, 2017

AAPT2 and PYDroid

AAPT2 has a strange issue it seems.

Let me explain how the PYDroid library is structured:

There is a core library, pydroid, which handles some extremely basic stuff that is common to all pyamsoft apps. Building off of this basic library is pydroid-util, which as the name suggests, includes utility functions that are not always needed. Building off of the pydroid-util library is the pydroid-ui and pydroid-loader libraries, which power much of the UI commonality you observe in pyamsoft Android applications.

When building Home Button today using the new Android Studio 3 goodies, I found that it was unable to fully build the project due to some resource errors, where application dependency's dependencies were not pulled into the main application. This meant that if pydroid relied on RxJava for example, it would not actually be pulled in to an application which relied on PYDroid, and so the application would either fail to build or crash when it finally did run.

It seems that changing the pydroid library's build.gradle file from using the new api and implementation syntax back to the old compile syntax fixed this issue. It's unfortunate though, since Android Studio 3 builds a lot faster with its new syntax, but it is fundamentally broken. I hope to port over the rest of the pyamsoft Android applications to the Android Studio 3 syntax now that this library issues has been resolved, and release an update later this week.

Stay tuned.

========================
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, October 17, 2017

Updates rolling out

Updates to all Android applications have been submitted to the store and should be live soon.

pstate-frequency was recently updated to 3.8.0 which cleans up the code base and removes support for the confusing x86_energy_perf_policy tool.

update-hosts was updated recently to include other blocklists such as cliqz tracking as well as admiral tracking.

Stay tuned.

========================
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
=========================

Sunday, October 1, 2017

License updates

Hey, so just a heads up.

All pyamsoft projects have been, or intend to be updated to use the GPLv2 license.

While this software license is perhaps slightly invasive with its "every derivate must also be GPL compatible" kind of virulent behavior, I do this for a couple of reasons.

1. I highly doubt anyone has actually taken the time to fork the projects, so this should not disrupt other projects. If your project was a fork of the original however, older versions are still licensed under Apache2 or MIT, and you are welcome to continue off from those older versions.

2. The GPL encourages the release of source code, which aside from software freedom (which is not really the main goal here) allows for any improvements made to the project by forks to be contributed back to the main project. This helps foster learning and new knowledge.

The projects were originally open sourced with the idea that because I had learned so much from reading open source projects to see their structure, others should be able to learn from me.

3. This will hopefully also discourage malicious knock off applications which simply copy the source code of the original application and then change the icons or text around a bit - effectively software plagiarism.

By making these licensing changes, I do not do so with the intent to harm other projects or prevent the growth of new softwares. I simply wish to create a positive feedback loop, wher new improvements to forks of the projects are given back to the community in an open and knowledge-encouraging way.

Thanks, and stay tuned for some actual Android updates, as well as some stuff from pstate-frequency, and thoughts about a next project.

========================
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, September 26, 2017

Delays

So I was supposed to update a while back.

But then I bought a new computer.

Then I returned said computer to buy a different one.

Now, with a working build inside of the tiny Metis Plus, I've found the time to prepare and upload the updates to all pyamsoft applications. They are currently sitting on the Play Store in open Beta, just waiting to be released.

Stay tuned.

========================
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, September 1, 2017

It's Almost Time

Just finished porting all of the pyamsoft applications to the latest stuff. PadLock, Pasterino, ZapTorch, WordWiz, Home Button, all done.

Testing now, hoping to get the first full release in a long while ready for next week, so that I can begin the cadence of weekly to bi-weekly release updates.

Stay tuned.

========================
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, August 10, 2017

Updates

Slower still, but steady.

Some notes about some changes. I've been doing a lot of coding the past couple of weeks, like a whole lot. It's burned me out slightly, but the drive to continue improving and understanding architecture of applications as well as design patterns keeps me going. I mention this for two reasons.

1. Release is going to be much slower than anticipated, since I will be re-writing yet again to expose myself to more of these styles and ideas in programming. My hope is that the resulting application will be clean to read, easier to extend, and faster to update in the future. Of course, plans never quite work out.

2. And speaking of plans never quite working out, the situation that I found myself in meant that for a couple of days, I would not be able to install Power Manager on my own personal devices. Days turned into weeks without the app on any of my devices, and I came to find that battery life on modern versions of Android had actually stayed the same, or generally improved in some cases. It seems that, due to Android becoming more locked down in this regard, or perhaps due to the design decisions I took when creating and updating Power Manager, it now has become more trouble than it is worth.

The modern, aggressive battery savings that Android proposes just have no way of nicely coexisting with Power Manager's aggressive requirements for radio controls as soon as the device switches into sleep, and the frequent periodic wake ups to turn off or on radios actually ended up draining more battery than the device would consume by simply putting its radios into a low power state - which the system does by default.

Because of this discovery, I am both pleased and saddened to announce that Power Manager is officially deprecated. I no longer have the need, nor really the want, to continue going against the grain developing an application that the platform does not want me to make. The last uploaded version should be relatively stable, so I will not be pulling it from the store, but no new updates will arrive in the foreseeable future.

I intend to fully update all of the pyamsoft applications that I still care to maintain to compatibility with Android O, as well as rewrite all of them in Kotlin. Luckily, aside from some of my adventures into application design and architecture, almost all of this is already complete.

pyamsoft will continue to be an independent, open source Android application developer. I will continue to develop tools that help people. I will continue to hack away at Linux, and Android. I'll continue to code, at least until this old machine dies and I need to buy a new one.

New PadLock is my current focus. I find the app useful for privacy focused minds, and it does not seem to intrude too much into the Android system vision. Right now, I am going through a full refactor of the PYDroid utility library, which serves as the base code for all pyamsoft applications.

Once the refactor is complete, I will update Home Button as a proof of concept and stability. From there, Pasterino and WordWiz will follow. ZapTorch is always a bit trickier, but it will come in time as well.

I'm thinking of doing one big chunk release, followed by small QOL updates every ~2 weeks. New applications will come when I have the time and the burst of inspiration.

I've sunset applications before. I said I would stop developing Home Button, only to turn around and continue maintaining it - even still to this day. This may not be the end for my friend Power Manager. It holds a special place as the first real Android application I set my sights on. I am happy to say that in this 2017 world, it may no longer be needed. Of course, the code is always open, if anyone wants to pick it up.

But if not - if this be its final hour - then so long, and thanks for all the fish.

========================
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, July 15, 2017

Slow but steady

So progress is slow moving, because I'm tired and lots of life gets in the way.

But rest assured, Power Manager 7 will be coming soon. It will make things simpler to handle, it will make it easier to automatically control power usage on your device. It will support Android KitKat to O. It will be written in Kotlin, because it's cool like that.

It will be easily extensible, so once its out the door, new features and modules will be much quicker to add. Version 7 will simply be the same old features as 6 but with better compatibility to more devices, but following that release, I wish to quickly add new modules for features, possibly things like GPS, brightness and APN settings.

PadLock will be updated following with a cleaner UI and lower memory usage.

All other apps will simply be updated with O compatibility and better performance, memory usage. No new features yet.

Kotlin everything, because Kotlin is cool beans.

Sit tight, sorry for the long wait.

========================
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
=========================

Sunday, May 28, 2017

Nice and Toasty

Normal day, as always.

Imagine my surprise to see this page pop up:







Toast leaked?
My innocent little Toast popups, leak the Activity context?

Curious, I dug in, and sure enough








When you call Toast.makeText(Context, String, Int) a TextView object is created using your passed in context. This means that if you pass it a Service, BroadcastReceiver, or Activity context, and the Toast lingers around longer than the Context you give it, you will leak memory.

The easiest work around is to call Context.getApplicationContext() on whatever you pass into the Toast creation method. However, this can be annoying, because you would need to go through each toast call and do this.

To work around this annoyance, PYDroid now ships with a wrapper utility class called Toasty which does this for you and consumes the standard Toast.makeText() API.

Assuming a simple use of Toasts, simply run a find replace over your project, and replace all instances of Toast.makeText with Toasty.makeText, and you should be good to go (assuming you have autoimport set to resolve conflicts automatically).

========================
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 27, 2017

Kotlin

It's new, it's cool.

It's a learning experience.

To this end, all pyamsoft applications will be re-written to use 100% Kotlin.
PYDroid has already been re-written to use 100% Kotlin code, and Power Manager version 7 - although still in progress - is also written with 100% Kotlin code and will ship fully running on Kotlin.

PYDroid in it's re-written Kotlin form should still be 100% backwards-compatible to its most recently released Java version.

Kotlin is cool and a neat alternative to standard Java on Android, and you'll be seeing a lot more of it in the pyamsoft future.

========================
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 20, 2017

Future Plans

Lots of nice changes to see at Google IO this year.

Future plans are going to be as follows:

Redesign Power Manager, release the new version 7. I'll have mockups/images soon for what the new flavor will look like, but its going to be simpler to use and more aggressive at saving battery out of the box.

Next will be a version bump to PadLock which will replace the tiresome swipe motions to pull out the navigation drawer for a simpler bottom navigation bar. Additional fixes to locking logic should bring better battery life and faster performance.

Media player application will be geared up for release next. Initial version will be intentionally simple, so that I can see what features work and which do not. It will also allow me to use community feedback to figure out what features are highly requested, and implement them sooner.

The theme of all of these changes is the same as Google's theme for its next Android flavor: performance, battery, and core vitals.

The incoming changes to the applications will make them more stable, better performing, and less battery hungry. 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
=========================

Sunday, February 19, 2017

Patch Sunday

Android stuff has finally hit production and should be trickling out over the next couple of hours.

Update and have fun!

========================
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, February 18, 2017

Testing Where

Testing testing testing.
Everybody always wants to have tests.
Would it surprise you to know that I have almost no tests? Of course it wouldn't.
But lets talk a bit about where we should seek to test and why.

In a basic Android MVP project, you can split your code up into mainly three larger layers:

The View

The Presenter

The Model

The View is dumb. While some people do like to write unit or integration tests for it, generally you should hope you don't have to. What's more important for the View layer is that it feels right, and that interaction with the application through various screens and flows doesn't do anything unexpected. It's probably the most dog food layer for testing. Generally you would just be dealing with direct implementations, Activities and Fragments and Views.

The Presenter is dumb as well. The presenter should serve a single, easy purpose. It should parse information from your Model layer and package it into easy bite sized pieces for the View layer to react to. It shouldn't need extensive testing because, well, it shouldn't do any heavy lifting. While we don't want to call this layer dumb, it should have so little logic in it that there is really nothing important to test. To make my point, many of my applications have a presenter which simply subscribes to an Observable and puts the RX operations on the correct scheduler. While some people like to make this layer accessible via Interfaces and then hide an implementation (as I used to do) it adds a large amount of extra files for no real benefits. You should be safe working with direct implementations here too.

A sublayer of the Presenter layer is the optional Interactor that many programmers use to define an interface which interacts with raw sources of data and parses it into something that can be consumed by the Presenter object. I use Interactors in my projects as well and enjoy the idea of a middle man object like a DAO. While the data they consume is ever changing, I like to fall back on the Observable object as the resulting something that I pass to my Presenters. The Interactor does some heavier lifting, it's job would be to take various sources of data and turn them into objects that are consumable by the Presenter, so there may actually be a lot of logic here. As such, you'd probably prefer to work with direct implementations instead of interfaces, because you want to know that your logic for parsing these raw types into consumable Objects is correct. You don't want to have a test double for your underlying logic.

Where you want to actually be able to drop in test doubles is in your Model. If you are able to double the data source and data stores, then you shouldn't care about testing the other layers. You would simply need to validate that your Interactor, Presenter, and View all perform the way you would expect given a set model. By making sure that various fake double models are handled correctly, you have validated that your logic is sound between the other layers of your application.

The real model is anything that you would consider a data source or data store. Databases, shared preferences, files, Android specific device components (like the Camera) should all be abstracted away behind a POJO interface where possible. Even things like your Retrofit interface which defines your endpoints, and your Autovalue classes would fall in this category. By being able to provide test doubles for a database operation, or shared preference storage, or even the response to a Camera request, you can validate that your logic in the application is sound. Because it is out of your control to handle things like the underlying Camera API or how Retrofit hit endpoints, you can rest assured that if your tests pass, its as good as things will get.

You can reduce the number of tests and interface doubles in your code to strictly the classes that are in the Model layer. This should help clean up your code and allow you to remove many redundant tests which may be duplicating or even replacing your production logic for Interactors, Presenters, and Views.

Or you can be like me and have no tests at all.

:)

========================
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
=========================

MVP is weird

So the more I read about MVP architectures as they apply to Android, the more I see things like this:

Presenter.java

class Presenter {



    DataSource ds = DataSource.get();
    View v;

    void bindView(View v) {
        this.v = v;
    }

    void unbindView() {
        this.v = null;
    }

    void doSomething() {
        v.onDoSomething();
    }

    void doSomethingElse() {
        ds.dataToObservable()
            .subscribe(data -> {
                v.onDoSomethingElse(data.stuff);
            });
    }

    interface View {
        void onDoSomething();

        void onDoSomethingElse(Stuff stuff);
    }
}


View.java


class View implements Presenter.View {

    Presenter presenter = Presenter.create();

    void onStart() {
        presenter.bindView(this); 
        button.setOnClickListener(v -> {
            if (condition) {
                presenter.doSomething();
            } else {
                presenter.doSomethingElse();
            }
        });
    } 

    void onStop() {
        presenter.unbindView(); 
        button.setOnClickListener(null);
    } 

    @Override public void onDoSomething() {
      doStuff();
    }

    @Override public void onDoSomethingElse() {
      doOtherStuff();
    }
}

That was a difficult process to write all of that psuedocode in Blogger. Not fun.
I'm curious to know where the Android practice of making the Activity or Fragment or whatever implement the entire View contract began. It seems like it clutters up the Activity with all of these callback methods that you can't really figure out where they are coming from or where they go to.

It seems to me like it would be much more efficient to implement these callbacks in separate contracts for the presenter instead of one large one, and have each presenter method accept a different contract. In doing so, you can keep the callback in a visually easy to read place - passed in with the method call to the presenter.

This way, while you are jumping around the various views and dealing with the already difficult to follow lifecycle methods, you can rest assured that your presenter layer logic won't just come out of the blue.

You can easily then trace the presenter logic by simply using Android studio to open the source file for the presenter, and you can see just where your callback is used.

Presenter.java

class Presenter {



    DataSource ds = DataSource.get();

    void doSomething(Something something) {
        something.onDoSomething();
    }

    void doSomethingElse(SomethingElse somethingElse) {
        ds.dataToObservable()
            .subscribe(data -> {
                somethingElse.onDoSomethingElse(data.stuff);
            });
    }

    interface Something {
        void onDoSomething();
    }
    
    interface SomethingElse {

        void onDoSomethingElse(Stuff stuff);
    }
}


View.java


class View {

    Presenter presenter = Presenter.create();

    void onStart() {
        button.setOnClickListener(v -> {
            if (condition) {
                presenter.doSomething(() -> doStuff());
            } else {
                presenter.doSomethingElse(() -> doOtherStuff());
            }
        });
    } 

    void onStop() {
        button.setOnClickListener(null);
    }
}

Sure it nests callbacks, which can visually not be as nice, but the code that responds to the presenter's action stays very local to where the presenter is invoked. And if you have lambdas, you can clean up the code to the point that you would barely notice the callback chain.

You'll have to make sure you release memory and subscriptions for your presenter onStop so that you don't accidentally hang on to these callbacks, but then again, you should be doing that already.

Visually your code will be easier to interpret and easier to read. It saves you from having to search through files just to find where you override a callback, and saves you from having to dig through files to find out which interface provides which contract for which presenter.

Brain dump off.

========================
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
=========================

A work in progress

Lots of fixes under the hood, but unfortunately no real new features.

Smaller APK sizes across the board. Faster performance, less memory usage, all that fun stuff.

Code is hopefully easier to read and go through and maintain.
I've been working particularly on stability in Power Manager. Older methods would prevent a lot of frequent automatic changes, I'm hoping with the new Android Job library backing the automatic queuing, the application will be more effective and more efficient.

DontSuck media player is actually nearing release, though its taken longer than I initially imagined.

PadLock now caches all of its large lists, meaning you only need to wait through the long loading time once, unless you wish to refresh the lists, which is still done in the same way.

Hoping to make a release over the weekend, but we'll see as time permits.

========================
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
=========================