New Android app that uses Akka

[Adam Mackler]

Hello:

In celebration of the final version  2.2.0 of Akka for Scala 2.10, I have published my first Android app to Google Play.  It is simple, but it uses Akka Coltrane, and seems to run without problems on all the emulators I tried.  It is a metronome app for musicians.

• Here is the published app.
  
• Here is the source repository.
  

Please feel free to download the app from Google Play and to give it a five-star rating. :)

Or at least if you find any problems, please let me know before you ding it.

Thanks to the Akka developers, and thanks in advance for any helpful feedback.

--

Adam Mackler

[Akka Team]

Hi Adam!

 

In celebration of the final version  2.2.0 of Akka for Scala 2.10, I have published my first Android app to Google Play.  It is simple, but it uses Akka Coltrane, and seems to run without problems on all the emulators I tried.

Great job! This will be very useful for those trying to run Akka on Android. Thanks for sharing.

Thanks to the Akka developers, and thanks in advance for any helpful feedback.

You are welcome! Happy hAkking!

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam

[Nikolay Artamonov]

Hi Adam! ) 

I'm pretty intrigued how you could build such small (1.6 Mb) application with rather large libraries like akka and scala stdlib? Sorry for offtopic, just curious! :)

[Adam Mackler]

I must confess, your question surprises me because 1.6 MB seems large to me considering how little the app does.  I feel that if I were more skilled with proguard I could make it significantly smaller.

Anyway, to answer your question, there's no secrets.  If you look at the project/proguard.cfg file in the repo, you can see the full proguard configuration.  I tried to minimize my use of wildcards, and that helps a bit.  Beyond that, I feel lucky even to have gotten proguard to work.

On Monday, July 15, 2013 10:03:47 AM UTC-4, Nikolay Artamonov wrote:

I'm pretty intrigued how you could build such small (1.6 Mb) application with rather large libraries like akka and scala stdlib? 

--

Adam Mackler

 

[Roland Kuhn]

Hi Adam,

I just tried it out and it definitely is a keeper (I’m a hobby musician too)! Thanks a lot for sharing!

Regards,

Roland

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

[Adam Mackler]

Thanks for the feedback and especially the rating/review!

On Wednesday, July 24, 2013 4:41:44 AM UTC-4, rkuhn wrote:

I just tried it out and it definitely is a keeper (I’m a hobby musician too)! Thanks a lot for sharing!

 

--

Adam Mackler

 

[Tim Pigden]

Adam,

Sorry to reawaken an old thread but there's still not much around about this.

From looking at the code it seems like you're initialising the actorSystem lazily in a global object.

Following the other thread on the same subject (where to put the system, whether or not to use services) did you basically come to the conclusion that you can throw everything in a global and only worry about the app being stopped completely rather than worrying about activities being stopped?

So for your original question about where to put stuff including services are we kind of substituting Akka for services altogether?

My own application is intended to be long-running (it's a truck-drivers track and trace app - the sort of thing the delivery man has you sign) but linked into truck's engine and back office system and with fancy rescheduling. This means I've got to listen to various things - sensors, responses from the server (which may take a long time due to gprs signal outage), broadcasts from the satnav and some long-running calculations.

I'm having a debate with my colleague about structuring the app and your previous questions about services and patterns is very pertinent.

I'm wondering if you've had any further thoughts - after all the metronome is not mission critical and it's quite hard to start make your android do different and interesting things while practising to your metronome - but your original question hinted you were planning a much more involved app.

Thanks

Tim

[Adam Mackler]

Hi Tim:

Thanks for your interest.  It's been a while since I looked at this code, so it's not very fresh in my memory.  Also, I'm not fully certain I'm understanding your question, so I'll just tell you some stuff, and hopefully what you want to know is in there.

My assessment of the "way" to integrate Akka and Android is that each framework has an essential base class and its own message-passing mechanism.  Those classes are Actor and Activity respectively.  The message-passing is done in Akka, as you know, using tell, a.k.a. "!".  The native mechanism for passing messages in Android is by passing a Runnable to Handler.post().  Integrating Akka + Android works nicely by figuring out where the Actor instances need to post messages to Activitys.  I know I'm being very vague since, again, this is not fresh in my mind, but if I were preparing a lecture on integrating Akka and Android, that would be the first thing I would want to explain in detail.

The next thing to understand is that one of my requirements for the Metronome app was to require no special permissions.  As best I remember, the only way to make sure the app would stop making sounds if an incoming phone call occurs without requiring a permission to read the phone state was to cause it to stop whenever the Activity is hidden.  Since the purpose of a Service is to continue running when an app's Activity is hidden, I did not want to use a Service, but that is a direct consequence of my desire to avoid requiring any special permissions.  Obviously if you're making an app for internal corporate use, special permissions is not something you would be worried about, thus no such limit on Service use would exist.

Finally, you mention the need for the app to respond to external events regardless of its state.  Without knowing the essence of the debate you're having, my first reaction is that my attention would go toward configuring the AndroidManifest.xml file so that your app responds to events as needed, even if the device has just been rebooted and the driver has not yet started the app.  That might involve starting a Service automatically.  Depends on the specifics of how the events are making their way to the device.

Knowing as little as I do about your specific requirements, I can say it sounds as if your implementation ought to be very straightforward, and the fault-tolerance that is possible with Akka can make your app very resilient to the connectivity interruptions your app can expect while operating on the road with the drivers.

--

Adam Mackler

[Sebastian M Cheung]

Hi Adam,

I just saw your post, and I am also keen on building more Scala based Android apps but I couldn't find any good tutorials.

So from your experience it was worth the effort that you managed to use Scala in Android?

Sebastian

[Adam Mackler]

On Sat, Jun 13, 2015 at 8:11 PM, Sebastian M Cheung <minsc...@googlemail.com> wrote:

Hi Adam,

I just saw your post, and I am also keen on building more Scala based Android apps but I couldn't find any good tutorials.

So from your experience it was worth the effort that you managed to use Scala in Android?

Hi  Sebastian:

Was it worth the effort?  Is that a trick question?  Writing an Android app in Scala must be less effort than using Java.  Actually I am unsure, because I've never written an Android app in Java.  Android apps require competent handling of concurrency, and trying to do that without Akka must be more difficult, no?

The main thing is that native Android provides its own mechanism to accomplish the equivalent of telling an Akka message,   See here.  You need to understand and integrate that with Akka's message passing when updating the UI.  Other than that, why hurt yourself on Java's concurrency?

It has been a while since I've done any Android programming, but I did release one app you might look at.  It's a simple metronome for musicians.  The app is on Play, and the source code is on bitbucket.  Note also that there are Scala+Android facilities I've never used and I'm sure there is much that's possible beyond what I have tasted.  Here are some promising links you might already know about:

• Scaloid
• An article about using Scaloid
• You probably already know about SBT-Android, which I believe is superseded by
• The Android SDK Plugin for SBT, which is currently maintained
  
• The scala-on-android Google Group

Those are just from my notes of a few years ago.  I'm sure the state-of-the-art has progressed since then.

Happy coding,

--

Adam Mackler

[Martynas Mickevičius]

Hi Sebastian,

also check out the Scala Days app by 47 Degrees which is done in Scala and uses Macroid.

--
>>>>>>>>>> Read the docs: http://akka.io/docs/

>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html

>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.

For more options, visit https://groups.google.com/d/optout.

--

Martynas Mickevičius

Typesafe – Reactive Apps on the JVM