Am I the only one who finds the layout of the Android app extremely complicated? Folders upon folders, how can you make your head around the various parts?
Yeah, as a developer this immediately intimidates me and I just move on. I thought we were out of the ages of "high ceremony" application structures. Apparently not.
Did you actually look through the folders? There are multiple projects. Theres a wearable project, a phone/tablet project, art (mock ups I guess?), the server code (3, actually. The content, some update server, and a push server), source for 5 library projects (these could just be jars), and documentation.
They do a main, release, and lpreview versions of the app code. I'm not sure why they would do this. Maybe they didn't want to hide it in other git branches? It is example code after all.
Huh? It shows practical examples of how to achieve and manage new material features with new API level and old. That's rather useful, especially since it shows just how Android devs THINK those APIs should be used.
It also shows rather well how to manage Android L vs. older Android split on Gradle level in a simple straightforward app.
It does look a little bit overengineered though. But it's far from being useless as a learning resource.
Guys, the folder structure is normal for gradle android projects.
I like this project, because it combines appengine, cloudstorage, android & android wear all together.
As you can see it also has a server component which reads the .json files from cloud storage of updated schedules. At least that is what i understand from it after looking around for 5 minutes.
It also contains a GCM (cloud messasing) implementation.
All in all, its a very cool that google open sourced this.
It is extremely good to have this kind of project.
There are not many places when you can have a look at how real apps (ie apps that are not trivial and deployed to real users) are architectured.
For this kind of real project with some scale, yes you are going to have a couple of libraries, a wear app and some flavors.
Also, the structure is pretty much intended to be abstracted by Android Studio.
The best part is the build.gradle files. They clearly show how to setup debug and release builds , multiple flavours , annotation pre-processing, multiple apks, etc. Something that took me 2 days to import my project from eclipse to studio. Very handy for all app developers who want to switch to gradle. Also, be sure not to release any app build with SDK v21 as it would be rejected by Google play.
Github is a much more social and connected platform than google code. Easier to find and fork projects and more of a neutral venue where different technologies can co-exist. Another interesting thing is that a lot of the google developers are on stackoverflow, which isn't google centric, but is very accessible as well.
Google is moving more and more code to Github (at least for public facing projects).
Google code is pretty much a corporate code repo from one decade ago.
I'm a bit disappointed there are no tests. I've always wondered how Google handles testing on internal Android projects (especially since it's a bit of a sore spot for Android [1]). It would've been great to see a "real world", official example.
20 comments
[ 5.1 ms ] story [ 67.9 ms ] threadThey do a main, release, and lpreview versions of the app code. I'm not sure why they would do this. Maybe they didn't want to hide it in other git branches? It is example code after all.
It also shows rather well how to manage Android L vs. older Android split on Gradle level in a simple straightforward app.
It does look a little bit overengineered though. But it's far from being useless as a learning resource.
I like this project, because it combines appengine, cloudstorage, android & android wear all together.
As you can see it also has a server component which reads the .json files from cloud storage of updated schedules. At least that is what i understand from it after looking around for 5 minutes.
It also contains a GCM (cloud messasing) implementation.
All in all, its a very cool that google open sourced this.
There are not many places when you can have a look at how real apps (ie apps that are not trivial and deployed to real users) are architectured.
For this kind of real project with some scale, yes you are going to have a couple of libraries, a wear app and some flavors. Also, the structure is pretty much intended to be abstracted by Android Studio.
[1] https://code.google.com/p/iosched/ IO 2013 app.
[1] https://github.com/JakeWharton/gradle-android-test-plugin#de...