Jump to content


Approved Members
  • Content Count

  • Joined

  • Last visited

About jacko9000

  • Rank

Recent Profile Visitors

783 profile views
  1. Apologies to the OP for my straying off-topic from Poweramp development onto web browsers which have inverted rendering. I think all posts on this have now been answered.
  2. The Pyrope code was forked, by Ninnix96 of xda-developers, from Gello browser, which is the standard browser on CyanogenMod 13. Pyrope was started initially to provide Gello down to Android 4, and to add a few extra features. I mentioned Gello purely because it has the best inverted rendering I have seen to date, and because I still use CyanogenMod 13 to access the Xposed Framework and also microG services, so I still have Gello. Neither Gello nor Pyrope have been updated in a while, so I use now Firefox Nightly with, in addition to the add-ons mentioned above, the "Dark Background and Light Text" add-on, which is also very good at inverted rendering. At some point in the future, I anticipate that the CyanogenMod team, which ended in December 2017 and is now called LineageOS, will copy the inverted rendering from Gello into the new LineageOS ROM browser, Jelly, which is being rebuilt from scratch and so is currently still quite basic. For your reference, the Pyrope support thread is at xda-developers: https://forum.xda-developers.com/android/apps-games/app-gello-browser-t3384782 They will be able to tell you if Pyrope is likely to be continued in the meantime.
  3. No problem. Google Chrome is way behind in this respect. All web browsers should provide a setting for inverted rendering, just as all apps should provide a light theme and a dark theme. Firefox Nightly is by far the most flexible browser at present. A couple of years ago, this flexibility held back its speed, but recent builds of Firefox Nightly are performing well on browser benchmark tests. A few other add-ons you might wish to use with Firefox Nightly, are: 1. User Agent Switcher 2. Android_new_tabs_in_foreground 3. Android Material Design (Blend Tab Bar)
  4. Not ripperino. Poweramp will not be affected by Google's "new" policy. See my previous post for the reasons why. I say Google's "new" (in quotes) policy because it's not entirely new; the support libraries (support-v4 and support-v7) have been available for developers to use since 2013. But most didn't bother, instead opting simply not to support older Android versions. But now Google wants developers to consider both backward and forward compatibility in their apps. Both of these concepts are built into the support libraries. I have been using the support libraries for the last two years, to support Android versions back to Gingerbread. The additional advantage being that, without having to change any code, the apps were automatically supported by new Android releases, also. What Google's new policy is essentially saying, therefore, is that it's time to raise the quality of the apps in the Play Store and to get rid of under-qualified developers, of which there are far too many. Google only has itself to blame for this by allowing such developers to publish sub-standard apps in the first place. But Google obviously now feels that it's time to separate the wheat from the chaff.
  5. Is that what you took from the article? Big G will do no such thing. This new policy from Google affects only new apps, and existing apps which are receiving updates. Existing apps which are not receiving updates, such as Poweramp in its current state, will be unaffected. And the backwards compatibility struggle is nothing new. Read my posts on this thread, from December 18th onwards, slowly (so that you understand them better than you did the article you have just read) to understand what Max needs to do to Poweramp, and what Google ought to be doing, but isn't, due to the ever-increasing number of "yes men" developers out there who just love Google and wouldn't do anything to upset Google, such as refuse to put apps onto the Play Store, but instead to sell them privately (which is what I now do), until Google begins to take more responsibility for backwards compatibility. If this is what Max is now doing, then good on him. I'll just keep rooting my devices and use Poweramp the way it is, for as long as Android exists. To summarise, in addition to Material Design, Max will have to use the Google Support Libraries, support-v4 and support-v7, to support Material Design back to API 14 (Ice Cream Sandwich) at least. Doing so will automatically allow all Android versions up to the latest to be targeted as a result. Which is why mastering these support libraries is now crucial, but far from straightforward, for all Android developers.
  6. Actually, HCI is what I specialise in, mainly now in air traffic control, where the user interface is of paramount importance. I can't say too much for secrecy reasons, but I can give you some examples. Colours must be easy on the eye, and able to be viewed for hours on end. You won't find black text on a blinding white background here; you might as well shine a torch in your eyes with that. There must be no reflections; the screen must be at an exact height from the floor and tilted back at a precise angle to avoid this. Fonts must be easy to read; alerts, when they happen, must be clearly visible; each control has a precise size and colour. Nothing is left out. Everything must be absolutely perfect, so that the controller feels completely at ease at all times. After all, people's lives are at stake. Having said that, this all comes after testing that the system actually does what it's supposed to. On top of that, these UI requirements are necessary for effective (and safe) use of the system, not to prevent the UI from looking "fugly". There is a difference. So, I do understand the genuine requirements of heavy use; I'm a heavy user, too, with sensitive eyes. This is why on Android, for example, I can only use web browsers which allow inverted rendering. Gello on CyanogenMod 13 (now called Pyrope Browser in the Play Store) in "night mode" is best at this, although Firefox Nightly with the "Dark Background and Light Text" add-on also does a reasonable job. Google Chrome? No thanks, I don't want a headache. But it was nice of you to offer. Incidentally, Google Chrome on Android doesn't use Material Design, and it is hidden on other platforms (in chrome://flags). As far as Poweramp is concerned, as I said previously, it was not necessarily the vote for Material Design which required the re-code from scratch; many app developers had to do this anyway when Marshmallow was released. However, the worst case scenario would have been if Max had implemented Material Design before Marshmallow was released. This would effectively have forced him to have to re-code the app twice, as many app developers had to do, due the overlapping releases of Material Design and Marshmallow. As a result, it has been a tough couple of years for Android developers, and I understand why Max has gone solo. About 18 months ago, I re-implemented an app during the Material Design/Marshmallow overlap period I mentioned. I carried this out alone; it would have been a nightmare to coordinate between multiple developers. In fact, all of my Android app development has been carried out alone anyway. Many developers do this, for two main reasons. Firstly, finding good Android developers is extremely difficult. Everyone thinks they're a developer these days. But they're not. For every app I install on my Android devices, I have tested several which don't make the grade. There is only an extremely small percentage of apps in the Play Store which I would regard as being of high quality. The second reason for developing alone on Android, is cost. Mobile software has become so devalued, and the end retail price of Android apps is despicably low, from a developer's perspective. This is great news for users, of course, who can buy exceptional software at a fraction of what similar software would cost on non-mobile platforms. So, paying additional developers (if you manage to find any good ones) is often just not feasible after paying Google its 30% share of the app price. Yes, Google takes 30% of the final price, just for providing the download service on the Play Store. Heartbreaking, to say the least. Thankfully, my app development has been for private clients, generally as part of a larger package on a non-mobile platform, so I provide the APK files myself, cutting Google out completely.
  7. The truth is, whether Material Design was requested or not, the app would still require re-coding from scratch because of the recent onslaught of Android version releases. There are now effectively eight Android versions to be supported (from I to P). Release M was a killer for many apps; I outlined the permissions model issue, for example, in my previous post. And from one Android version to the next, API functions are deprecated, which means additional version checking within the code, sometimes requiring sections of code specific to each version in order to accomplish a particular task. The use of the support libraries is crucial in this regard, in order to handle these multiple Android versions. A full understanding of these libraries, and how to use them, is required by developers as there will always be a need to support previous Android versions, as well as to prepare the app for future versions. So, yes, I believe re-coding is both necessary and beneficial at this point, albeit time-consuming, frustrating, and sometimes soul-destroying. The criticism I put to googleboy2011 is that Google really ought to be more active in assisting developers to support past, current and upcoming Android versions. As it is, Google are offloading the weight onto developers, and it's leading to code duplication on a gigantic scale; there are thousands of developers all having to write the same code as each other, rather than the code being written once at the source (i.e. by Google). But I don't doubt Max's ability to make the best of the resources provided by Google. Far from it. As a former development team leader myself, I can tell when an app is well-written, and Poweramp falls into that category, as it did when I first used it back in 2012. I had been watching this thread for a while. I rarely post on forums (as you can see from my profile), but felt the need to clarify things from a developer's perspective. As far as the poll result goes, I thought I read at least one post on this thread which stated that functionality updates should take priority over UI. Personally, I would agree with this; I would place functionality, stability, reliability and performance above UI. Criticisms that an app "looks old" are a bit beyond me. Ultimately, however, if it's what users want, then that's what needs to be done, but they have to be made aware of the cost involved, in terms of timescales, and I felt that was one of the points, along with a few others, missing from this thread.
  8. Users who demand cosmetic changes are the ones holding back innovation. I tried to explain to googleboy2011 that the Material Design support libraries, support-v4 and support-v7, offered to developers by Google, are not straightforward to use. Google tout Material Design as being modular, a dream to work with. But this only applies to new apps, which is why Max will have to re-code Poweramp from scratch. Max's problems will be further compounded by the allow/deny permissions model introduced in Marshmallow. This in itself requires app code to be completely re-structured in order to handle the user's choices. Often it doesn't even make any sense to ask the user for permissions when an app can't work without them. Yet the user must still be asked, and they can still say no. A logic nightmare ensues in the application code. And Max will have to decide on his use of the support libraries to support Material Design on Android versions back to a specified API level as far as 14 (Ice Cream Sandwich), in order to retain as many users as possible. Of course, he doesn't have to; he could just say "f" anyone below Android 6 in order to simplify development and testing. It would mean he would "only" need to test on Android versions M, N, O and P, as opposed to I, J, K and L also, effectively cutting testing time by half. In conclusion, those of you who thought Material Design was just a few simple changes to layout, colours, and buttons, have been sorely misled by Google (maybe not for the first time?), and it is Google to whom you should be expressing your frustrations. The fact that you are unlikely to get anywhere doesn't mean you then turn to the developer for an explanation. I've given it to you here; you'll get it when it's ready. It's not possible to give timescales when developing under such conditions, as each new day throws up unforeseen problems which shouldn't even have to be dealt with.
  9. Yes, it's about moving forward, but the "liability" (as you correctly described it) is the responsibility of Google, not of the app developer. There was a time when OS manufacturers took it upon themselves as failure if OS upgrades broke third-party applications (before your time, perhaps?), but it has become the norm now. Nevertheless, Android is nothing without developers, and if these developers refuse to run simply to stand still, as Google increasingly expects them to do, then developers can ultimately just pull the plug on their app and move on (Max, are you listening?) And to say that Google provides enough backwards-compatibility help to app developers simply isn't true. The support-v4 and support-v7 libraries are a shambolic joke; they are no more than a token gesture, a mere drop in the ocean, from an organisation with vast resources, who are (and I'll use your term again) liable for app breakages upon OS upgrades. Yes. They are.
  10. Poweramp is neither "way outdated", nor "vintage". Users should routinely be asking Google to ensure that new releases of Android are backwards-compatible with existing apps. Has anyone opened a support request with Google on the matter? Because that is the solution. It is Google who is at fault here, not app developers. And it applies to all apps, not just Poweramp. Google ought to be continuously flooded with millions of backwards-compatibility requests from users of all apps from all over the world. And app developers should stand firm and refuse to jump through the hoops created either by Google with their lack of backwards-compatible releases, or by users who fail to see that the onus is on Google to build such compatibility into new releases of Android.
  11. Thanks for letting me know. More specifically, I would like to see the logical extension of preventing duplicates within a playlist, to preventing duplicates across all playlists, so that each song may be a member of one playlist only. Regards, Jacko
  12. Hi, Since the previous post is now over a year old, please could someone confirm whether or not it is still correct. I would like the ability to see which playlists a song has been added to. Thanks for your help. Regards, Jacko
  • Create New...