SIMPLIFYING Native development for The world's most popular mobile platform
{
Under
Construction
}

What

DEPENDENCY-ORIENTED framework for building native Androidâ„¢ APPLICATIONS
More
h

DEPENDENCY-ORIENTED?

An internal architecture that facilitates instant reuse of combinations of Android libraries

COMMUNITY-DRIVEN

Simplifies sharing recipes that interconnect the best of Android's ecosystem (Ă  la ChefDocker, Puppet..)

BEST PRACTICES

Presents selections of modular, organized and curated Android best coding practices

RAPID DEVELOPMENT

Offers a Vehicle to quickly kick off your journey with all that's needed to start writing your business logic

Your
Experience
Underneath, We're all the same

Android Getting Started page can feel like foreign lands to Java developers. AoW can be a cultural bridge that makes sound decisions for you and ease you into this new world.

PATTERN Agnostic

Standard Android? MVC? MVVP? MVP? MVVM? VIPER? Flux? Clean? SOLID? Hybrid of all or some? Bring it with you! Have your own set of preferred libraries? Bring almost* all of them too.
*There might be some rare cases of allergic reactions when using AoW

Underneath, We're all number one(s & zeros)

There's a widening wedge between cross-platform frameworks lovers and those who tolerate nothing but the best of both worlds. If you're of the latter, then you admirably put stupendous time and resources to resolve idiosyncrasies on each platform. Though we can't promise a resolution at this point, a superior solution might be what you need.

FRAMEWORK TINKERER

Afraid you'll dislike some of our architectural decisions? Learning curve for you and your team makes you hesitant? Whatever it is, tinker! Step away from or closer to our approach. Easy customizing is great for AoW as it helps it slowly invade your existing large apps.

Why

Random Conversations in the life of an Android Developer
More

me

04:53 PM

Hey dude, what are you working on?

CJ

04:55 PM

was just done adding library XYZ to one of our apps. I love it now but was pulling my hair out for days until we smoothed out the wrinkles

me

04:56 PM

i feel u. had to do it couple of weeks ago and it was a pain in the butt to get it to work with library ABC

CJ

04:56 PM

lol, this is the EXACT issue we spent most time on. sometimes i feel we're just reinventing the wheel

me

04:56 PM

speak for urself man. I've never reinvented more than 99% of any wheel

me

10:11 PM

How's progress with Android?

SI

10:29 PM

Still learning but I couldn't imagine how different it is from typical java desktop or server apps. very different UI, life-cycles, threading issues, and no Spring to help! +15 years working with java yet this makes me feel like a college kid all again

me

10:30 PM

all true. Hey at least it made u feel young :b, did you check code path http://guides.codepath.com

SI

10:29 PM

I did and it's an awesome resource. tbh though, the length of that page and number of links there can cause, ah, a noob-shock

AR

01:25 PM

i'm loving this new bootstrap project github.com/stutter/yetanotherandroidbootstrap

me

02:03 PM

nice libraries and organization. though i have to say not a big fan of all these annotations

AR

02:06 PM

For me it was the ORM. I couldn't stand it so I spent last weekend replacing it plain old sql. I wish there's a single sensible bootstrap project I can just reuse. Updated too would be awesome!

me

02:20 PM

lol. i do like some best-practices i find in these projects but I think it's impossible for one to fit all tastes and needs. after all it's more or less a static template

me

11:37 AM

So why are you applying for the Android Intern position?

CS

11:37 AM

Well, as a college senior the majority of our courses involve either Java or C++, mostly Java for me which I like. I tried to pick up Android on my own but it had a steep learning curve so I couldn't do it during school time while along with my part-time work. I did work on other Java applications using Spark

me

11:37 AM

Understandable. I'm sorry to tell you though that the position is only open for someone familiar with Android. So unless you put everything else on in your life on hold and glue yourself to a screen learning Android for the next couple of weeks, I don't see how you can be ready by the internship start date. Sorry.

Why Now

The *stars* are aligning
More

Gradle & Plugin

Things are getting bigger

Frameworks such as Grails and Spring switched to Gradle and for good reasons. Important for our purposes is its dependency management and the simple plugin mechanism that eases modularization and organization.

On Android, the Gradle plugin's recent addition of Transform API is a sign of more and better support of deeper architectural changes on the platform for troublesome devs like us.

Android Universe Flourishing

"There's a library for that"

Hundreds of libraries were and are still being created and many became a quasi-standard in the industry. The passage of time has also cemented many best-practices to be found in libraries, bootstrap projects, templates, blogs, etc. Those gems can make apps (and life) much better.

Size Matters

But ProGuard is a superb Cleaner

Though not new, ProGuard's shrinking is worth mentioning as it "produces the best results for programs that use only small parts of their libraries." Regardless, to counter this and the 65K Dex nightmare we're considering a couple of alternatives. Drop us a line if you have an amazing idea.

Compilation-Time SUCKS

but new solutions are actually helping

Whether it's Buck, its Gradle cousin OkBuck, JRebel or Android's own Instant Run efforts, all of these are mitigating the horror of this problem. Almost all of these solutions  use some type of incremental building that makes working with Android libraries specifically a non-issue.

HOW

We have an open hood policy (Caution: WIP)

Axle

Conceptual

The core plumbing module responsible for mechanisms that simplifies:
- Connecting all parts
- Inversion of control
- Extensibility

The Axle actively avoids decisions or code not essential to its mission. AoW defers mostly to Wheels for such functionalities. 

Technical

An Android Library module that
- All AoW main parts depend on directly
- Runs in its own process
- Provides a tight feedback loop by hosting multiple components together

Wheel

Conceptual

The natural repercussion of working with multitudes of simpler and interchangeable dependencies, each with a distinct API and varying functionalities, is more boilerplate and glue code. Wheels are just that; a community-approach to mitigate this legwork so AoW can maintain the modular structure we all like.

Nothing radical here. Chef Supermarket and Docker Hub are but a few examples of efforts with the same underlying concept.

Technical

An Android Library module which contains:
- At least 1 dependency on a community library or AoW Wheel (all combinations are acceptable)
- All glue code needed to make all contained libraries work instantly when this Wheel is added to an android app using AoW

Wheels creators are encouraged to submit them to AoW Store. A Wheel will be published as long it fulfill the definition above and it contains only public libraries. Wheels should also note if they are mutually exclusive with any other Wheels or libraries.

Gear

Conceptual

Gears are similar to Wheels except they contain no dependencies. Utilities, helper classes, config methods and classes adding or overriding AoW defaults, etc. all belong here.

It's encouraged to factor an application into a set of modular gears away from business logic. This enables reusing, sharing and improving gears. A project could instantiate an application object, initialize several Wheels, and register a collection of gears.

Conceptually, Gears are a bit similar to Flask's Blueprints.

Technical

A Gradle module
- No dependencies
- Cohesive: though this is best inferred from community usage, some overarching theme should explain the Gear to be useful. Think showcases, not garages.

Wheels are encouraged to be single purposed modules

Rim

Conceptual

For themers! Stay tuned.

Technical

Vehicle

Conceptual

The combination of an Axle and any number of Wheels and Gears results in a sleek AoW Vehicle. 

AoW Vehicle is the most opinionated part of AoW as it aims to include all is needed to for production use. Though it does so by making many decisions, it does it through Wheels and Gears which can be easily replaced and removed. The aim is to provide a gentle guidance.

AoW Vehicle gently enforces encapsulation, an intuitive code structure, offers you abstraction layers for many aspects of Android, it does not missionize you. Wherever you want, you may fall back to the Android Way.

Technical

An single, empty Android Library module that acts as a container of dependencies of an Axle along with Wheels and Gears.

AoW Vehicle has many configuration values, with sensible defaults, and a few conventions when getting started.

WHY LIBRARIES

The whole is greater than the sum of its parts
More

Diversity can be powerful

Hardware constraints and unprecedented scenarios that Android developers deal with created a culture espousing nimbleness and heterogeneity. A framework, to succeed in this environment, must grow respectful of differences, actively seeking to relegate choices to their rightful makers.

ADAPTABILITY

Standalone libraries are fairly interchangeable. When a library is no longer suitable, for internal or external reasons, it's less of a headache to replace than rebuilding an entire module. True for an app, true for a framework.

EVOLUTIONARY MODULARITY

For libraries to survive, they must ensure appealability to the widest audience possible and narrow or widen their scopes accordingly. More beautifully, they have to do so within the context of other competing, overlapping and complementary libraries.

Manifesto

thou shalt NOT REINVENT THE WHEEL
More

WITH GREAT FLEXIBILITY, COMES GREAT RESPONSIBILITY

Promoting a vibrant community of individuals and organizations eager to help build great things around AoW is not an objective of this project; it's a survival necessity.

To ensure an awesome ecosystem we must involve when making critical decision, guide by example (and building examples), facilitate all types of input via simple channels, and, possibly, nudge the community when and where it needs it.

No strings attached

Aside from `Android`, `Apache`, `MIT`, nothing proprietary should be welcome in our core. Proprietary technologies and contributions are always welcome as external Wheels.

If there's any dogma that AoW team should live by, it'd be to emphasize that this is first and foremost a community project.  It is our responsibility then, at all points, to ensure that such a community of the people, by the people, for the people, shall not perish from the interwebs.

Controversy-Averse

Rather than shoving opinions down colleagues structures, we should be extra modularistic around community-divisive parts and push them into external components. Again, leave those decisions to their rightful makers.
We shouldn't, however, shy from such matters when building collections such as AoW Vehicle. That's where our input/opinion/conventions are expected.

Modularize from the inside out

Hype it is not. If, while building any internal part or feature, a gap was found which can't be satisfied by an existing community library, the first and foremost question should be how can we build something here that can be released as soon as possible as a useful community library?

This line of thinking, this mission, forces the type of creative modularity that great system architects embody.

Forward Thinking

Great software and frameworks have lagged due to the nice-soundness of Backward Compatibility. A Diminishing base of happy users and a change-averse culture follows. Nothing to aspire to.

Forward compatibility is developing with an eye for future of  code extensibility and is in the true spirit of modularity. Nevertheless, predicting such things in all possible ways is impossible. In those instances, lean forward.

KISS inside, KISS outSIDE

Counter-intuitively, it's actually easier to build something complicated. I mean who has the time and resources to design..Let's just build it and then sugar coat it with a cool API. Milestone achieved, deadline is met and release train has left the building, yay!
Away from crazy rants, why not just give simplicity an equal seat at the table when working on code, be that external or internal. Not all can be simple, but at least we made a dent for the next generations.

about Andy on Wheels

A rapid development framework with an evolutionary bent that simplifies Android programming for its current developers and others interested but don't have the resources required for a steep learning curve. This new approach offers solutions for recurring issues in the regular development process