1. Ok, that's a lie. When that live wallpaper that has an AI Super Mario that plays never ending levels came out I spent a lot of time looking at it and showing it to people. My Motorola Droid's battery didn't stand a chance.
Besides that, my argument is that if a you spend a lot of time in your launcher, it might affect battery life in a somewhat noticeable way. Typical usage should have you in another app most of the time, but that's speculation on my part. I could imagine folks using their launchers a whole lot if they were packed with widgets that did more than just display things, but I've never had a lot of luck finding widgets I liked. Ultimately, if you or anyone else is concerned about squeezing every possible minute out of your battery, your best bet might be to have a solid black static wallpaper. Mostly comes down to priorities.
Edit: http://android.ccpcreations.com/mariolive ⇐ I think that might be the same live wallpaper from back then? Can't verify it right now, and I'm wary of installing foreign APKs these days, so exercise caution.
https://github.com/yareally/android-scala-intellij-no-sbt-pl...
I spent weeks trying to get sbt to play nice. I finally said, the hell with that, and I never been happier.
Thanks a lot! Good work!
That also makes it difficult to introduce new features since I can't just switch them on and I don't really want to pester users about it. Not entirely sure how to handle that yet, but I've been focusing on other personal projects and job hunting. Worrying about adding stuff to Ascension hasn't been a huge concern. It does what I want, so I haven't found anything else I'd like to add to it just yet.
I actually liked a faster "wave propagation" speed.
All personal taste though, which Android excels at. =)
edit: never mind, you block galaxy nexus for performance reasons.
awwww :(
Because of the issues, I decided it was better to just block the device entirely rather than have people suffer through the performance issues with the Galaxy Nexus.
The important thing for me was that it compiles to JVM bytecode that's compatible with Java 1.6, so the resulting code can all be converted to Dalvik fairly quickly. The main downside right now is that you have to heavily prune the Scala stdlib, since it's packed with tons of methods and dex has a 16-bit method limit[1] — and you will hit it if you don't prune it (using proguard or another tool of your choice).
[1]: https://code.google.com/p/android/issues/detail?id=7147#c6
I stick to using Java Collections (and the special ones Android provides[1]) most of the time to avoid excess overhead, but it still results in much more concise code than what I would write in Java. One of most compelling reasons to use Scala though is it's much easier to deal with asynchronous processing (via actors, futures, async/await[2]) than the messes you end up with using AsyncTask + callbacks with Java.
[1] http://developer.android.com/reference/android/support/v4/ut...
This is definitely true, though it's possible to write code that avoids it. It just ends up being slightly uglier Scala. The renderer in Ascension, for example, is all fairly bare-bones Java-like Scala because I have to be careful about how certain code is generated (i.e., prefer a while loop or tail recursion to a for comprehension or .foreach). So, it's possible to get performant code, it just ends up being more like Java usually.
In the UI code, you can get away with a little more depending on where it is. If it's inside an adapter, it pays to avoid the heavier tools Scala gives you. If it's responding to a button press, you probably don't need to worry as much. The GC will run a little more often, but the GC in Android has improved a fair bit over time.
I'll second the Java collections recommendation though — as much as I like the immutable collections provided by Scala (and I do use a few of them), they're much free-er with their allocations than Java and Android's. I haven't tried anything with actors on Android yet, though, so I can't comment on that. I just use AsyncTask as carefully as possible right now, but I really need to get familiar with an alternative to that. I'd like to try actors, plus I'd also like to get into using something like RxJava/Scala, but I haven't had anything come up where I could afford to experiment with it. Also need to see how Akka fares on Android, but same problem as RxJ/S.
For the 25%: wouldn't they just decompile the current version?
I'd be more than happy to help de-spaghetti the code if it was available.
Plan for now is to release it under the GPL version 2 or 3 to hopefully compel people to make their modifications available (plus there's not much use for a lenient license here -- it's not a library, though some of the code could be moved to one later). This might take a day or so, so I expect this post to disappear into complete obscurity before I'm done. Might create a new HN submission for that just to let people know. At any rate, my net access is down so I have to write this on my phone, meaning any release is going to wait on my ISP to determine what's up and how to resolve the issue.
So, open source is planned, I'll just suck it up as I usually do when I release every other project of mine. Re: malware, I've decided it's not my responsibility to protect people from the malicious few. I'll let Google do that.
but I understand the 25% bit. It's a shame the android market is so hostile.