I just published Auto Respond 1.2.6.
Not a whole lot of changes in this version, but I think they are important changes:
- Finished standardizing the look and feel throughout the app
- Settings screens now have “OK” and/or “Cancel” buttons in them
I just published Auto Respond 1.2.6.
Not a whole lot of changes in this version, but I think they are important changes:
I just spent a few minutes polishing up my layouts.
I realized the other day that there was yet another neglected window when I did my redesign… the “Do Not Respond” window.
Part of the reason why I forgot it is because it’s buried in the settings, and I cannot apply quite the same design to the settings window (or at least not easily… maybe I’ll look into that as a possibility.)
So I just spent a few minutes reworking that window as well. It was a quick and painless transition, but it isn’t really enough of a change to need a new release (especially since I just put out an update this morning) so I’m going to sit on it for a while, and it will be included in my next release.
Since I just mentioned it (and literally just thought of it as I was writing it) I will look into the possibility of adding a cancel and OK button to the bottom of the settings screens, to keep that constant with the rest of the app, but I’m not sure if that’s easily done. I may have to literally rewrite ALL of the code for those screens in order to make that possible, instead of just rewriting the layout and a small bit of logical code. If that’s the case, it will not be done. But if there is a way for me to easily add buttons to a settings screen, I’m sure I’ll find it.
Until next update, let me know if there are any feature requests or lingering bugs. Otherwise, you probably won’t hear from me for a week or so. I have family in town this weekend, and will likely be spending the next few days with them instead of my computer.
Happy holidays everyone! I hope you all get all of the presents that you asked for and, as always, stay safe!
I just published an update to Auto Respond. Not much in the way of changes, but I may have potentially finally killed a big bug.
People have been emailing me, saying that sometimes my app doesn’t send a response. Some people have sent crash reports when it has happened, all of the crash reports pointed to a “null pointer exception”, but I couldn’t figure out where exactly it was happening. (Even with all of the information provided in the error reports.)
Today I was going through my code, block by block, and commenting it thoroughly, in case there comes a time when I put this away for a while and return to it months later. While I was doing this, I finally realized where this error is possibly being generated. (And possibly fixed some other errors in the process.)
That being said, here’s the change log:
Yesterday I started playing around with Google Analytics, and figuring out how to build it into Auto Respond.
The versions that are out now do not include Google Analytics in any manner, but I am looking into possibly building it into future versions. That would mean that the paid app would once again need internet permission in order to send the data back to Google, but this would be the ONLY information sent and there would be no personal information transmitted.
For those who aren’t aware, Google Analytics helps developers understand how users are interacting with their products. It will tell me how many times specific screens are viewed, how many active users I have, and potentially which buttons and other elements are interacted with most often.
This information can help me understand how you, as users, interact with my app. It can tell me which things you use often, which things you never really use, whether you tend to click buttons more than list views, and possibly even what settings are used most often.
I’m not sure of the exact information I can get, as I have just started playing with it, but rest assured that I will NOT be able to see that John Smith opened the app x times, or click this button, or has these settings set. I simply get a report for ALL of my users and cannot tell the difference between interactions from one user to the other. (I do not need, or care about, statistics on a per user basis in order to get useful information.)
I can then use this information to improve the parts of the app that are used most often. If people tend to use the scheduler a lot, I can spend some extra time with new features to give you more of what you want. Or if people use the preset messages a lot, maybe I can add more information to the list view, or create new sorting options, etc.
Or, on the other hand, if people tend to not click on my list views, I can make it more obvious to the user that clicking on the object will cause some action.
Overall I’m very excited to see what I can do with this tool! And once it’s set up I think it can greatly help me improve interactions in my app. The ONLY downfall is that the paid version will require permission to access the internet, which I think is a small price to pay for an improved app.
Let me know your thoughts, and if you have any experience with Google Analytics, feel free to let me know how it worked out for you!
TL;DR – Google Analytics will potentially help me understand how my users use my app, and help me improve the user experience.
I just released a new Auto Respond, this is only for paid users. The only difference is a new sorting option for schedules.
Unfortunately, I was in the middle of working on this when I released 1.2.4.2, and included the incomplete code in that version, so I decided to finish this ASAP as to minimize problems. There will be even more sorting options in the future.
If you are using the paid version of 1.2.4.2 DO NOT sort your schedules until you update to 1.2.4.3. If you do sort them prior to updating you’ll likely end up with duplicate schedules, or missing schedules, and you’ll end up needing to delete them all and recreate them.
The new version was just published, and should be publicly available in an hour or 2.
I just pushed an update to Auto Respond.
Here’s the changelog:
1.2.4.1:
(Paid)
1.2.4:
(Free)
For those who are wondering how I’m distinguishing paid features from free features, I’ve come to the decision that anything that allows you to bypass seeing the ads will be a paid feature.
The whole point of a free version is to attempt to generate revenue from users clicking ads, and to give the user a free “trial” of the app. But if you never see the ads, there is no chance of generating revenue. (I use “trial” for lack of a better word. But the free app is obviously fully functional, and without an expiration date. The paid app just has more features.)
This means that the following features will be paid only if/when they are completed:
To get the best of both worlds (allow users to use the dock feature, but also have them see an ad) I have added what is called an “interstitial” ad when you undock your phone. This will pop-up a full-page ad when you undock. It will only show up if Auto Respond is being turned off while undocking. This means that if you are not using the dock function, it will not randomly pop-up ads on you while removing your phone from a dock. (Of course, this ad only appears in the free app, not the paid app.)
This ad has been in the app for a couple versions now, so if you are using the dock feature, you should be seeing an ad when undocking.
I hope you agree with this decision, as it’s the best solution I could find that satisfies you as a user and me as a developer. If you have comments or questions, don’t be afraid to express them.
I just pushed another update (lots of updates these last couple days!)
Change log is small, especially for free users:
(Paid Only)