I've just published a new draft of Episode 2, including:

- a review of Chapter 2 based on feedback from readers. I've clarified a few points and added some activity diagrams to visualize the most relevant interactions inside the android core that we want to advise.

- Chapter 3. Here is a complete discussion of the code required to implement the feature discussed in the previous chapter using aspects.

- Chapter 4 (reflections) right now is just a random collection of notes and reminders; I'm publishing the real draft I'm using, not a cleaned-up document.

Would be nice if you could share : ), and of course, I'm interested as always in your feedback.

A draft version of Episode 2, with just Chapter 1 and Chapter 2 completed, and with a few pointers (mostly to remind myself) to the contents of chapters 3 to 6 + Appendix A and B, is now available for download. 
If you read Episode 1, the introduction may look similar, as I'm describing the same exploration project, but it's actually different, as Episode 2 is completely different in intent from Episode 1.

I'm publishing Episode 2 one chapter at a time, as I'm quite busy these days and I don't want to delay the ebook too much. Also, I'm interested in gathering some early feedback on this work.

The kind of feedback I'm looking for:

- comments on the readability / comprehensibility of the text itself, both from the perspective of someone knowledgeable about the android internals and of someone with no previous exposure.

- flaws in contents or reasoning.

- ideas and perspective on things, which may also influence chapter 4.

- obvious typos etc. :-)

What I'm not looking for:

- dogmatic feedback based on religious attachment to some approach or notion

- meticulous copy editing (not that the text doesn't need it :-)


Thanks you all guys, and if you like it, share it :-).

Episode 2 is taking me forever, so here is a status update:

- all the code is ready and working. I may tweak things a little while writing, but overall it's all there.

- the integration of aspectj inside the android build process is much better than my first attempt. Still sort of hacky, but very simple to use (you just add the aspectjrt jar file to the static libraries list inside a makefile, and everything works, the module gets compiled with aspectj).

- all the more "academic" stuff like analysing the cross-cutting concerns in the android core has been trashed as I moved from android 4.4 to 5.0, and I'll have to do that from scratch.

I expect to write the ebook out of order, that is, start with the chapter on actually implementing the changes with AOP, then writing the reflections chapter, and leave the introduction and the appendix on integrating aspectj last. I'll probably publish some work in progress version, but it's going to take time - I don't really feel like writing these days.

Overall, the feedback from episode 1 is that people hate AOP (or whatever is not FP) so much they won't even bother to take a look :-). Sort of expected, but perhaps slightly worse than I expected. It's ok, of course: I'm doing this to learn and think, and then to share what I've learnt. Takes just a little more focus and determination when you know just a handful of (good :-) people will take a look.

While replying to a comment in the discussion group (concerning the implementation of a Ribbons-like app using the DCI approach), I proposed a change in behavior, because changing our software is an excellent way to learn about its real properties. 

The change was seemingly simple: while in the Ribbons app the Surface acts as both an input and an output panel (that is, you move your fingers on the Surface, and you draw on that same Surface), it would be interesting to see how hard it would be to separate input from output, that is, having an input Pad separated from an output Surface.

I tried the exercise myself, of course. I also wanted to explore a few more twists: Will simulated input keep working? What would it take to enable both the Pad and the Surface to act as inputs? More importantly, will it work with multiple, independent Pad + Surface pairs?

I started with something simple, that is, how would I like my XML layout to look like for two side-by-side Pad + Surface pairs (with each Pad under its corresponding Surface)? 
I concluded something like this was ok:

Episode 2 will be quite different from Episode 1. After all, the idea behind this project is exploration, not repetition. So, for Episode 2 I decided to jump from app development to making changes inside the android core. I've got quite some experience in the past few years tweaking android for embedded systems, and I think it will be interesting to approach those challenges from the aspect-oriented perspective.

So far, these should be the major topics (not necessarily in this order)

- Cross cutting concerns in the android platform code.
I did an interesting investigation to find out cross-cutting concerns in a sort of low-tech, tool-assisted ways, as one can't really pour through million of lines. 

- Why google should be using aspects in the android platform code 
(short - subparagraph; also reference other works in BSD and an alternative approach from the XDA community)

- Why we should use aspects to customize the android platform
(short - subparagraph)

- AspectJ inside the platform: how
Integrating a new compiler within the android build system (+ the ability to recompile at module level using the new compiler) isn't really straightforward. After a few dead ends, I ended up creating a compiler wrapper for aspectj; this approach would probably work for other languages that compile to the JVM too.

- A manageable but non-trivial change
Unless I change my mind :-), I'd like to add a realistic (and useful) feature that requires coordinated changes to the USB service, the Power Manager service, the Settings service and (potentially - won't do that part) the WiFi service.

- As in episode 1, reflections / insights
we'll see what comes up here :-)

It's going to take a while to put all this together - I haven't finished the code yet. I may even decide to try publishing a portion of this material elsewhere first, or present some to a conference. I'll keep you guys posted.

Join the discussion group to talk about this stuff and more!