(Part 2) Best products from r/androiddev

Everything starts w/ making a good product

Marketing

• Find a niche, go to where they go and target them with thoughtful cool posts like /u/koleraa and /u/ccrama said. Be real, responsive, and follow up
  
• This works better for apps than games b/c you can engage ppl in problem solving your app, but I'm sure there are gamer communities
  
• For a game you might need more of a "stunt", read Growth Hacker Marketing for ideas here
  
  Don't have a "leaky bucket"
  In normal words: make sure ppl who install your game have a good experience right away and come back. Set up analytics so you can track this. If you are failing, work on the game and don't market yet. You should watch all of these free Y Combinator online startup classes, but #6 is most relevant here.
  Design the game to be viral
  This is where you've got it easier than normal apps, games can be designed to share and engage other users. I recommend reading Hooked for ideas on how to build a habit forming app that ppl will want to share. NOTE: annoying tricks don't work and no one wants that.
  
  Crossing the Chasm is less relevant to a game but an insightful classic on the old "how do I develop a market for a technology product".
  
  All of these strategy require focused and consistent effort to have a chance. I'm in the same boat you are so hopefully we can make something happen :)
  
  BTW I'd be happy to share my notes on all these books if ppl are interested.

Not Android, but, much of what konk3r said in his comment is packaged nicely and easily consumable in Refactoring by Martin Fowler. Before you begin coding Android, understand Java and what it takes to write maintainable code. Any mildly intelligent chimpanzee can write code; it takes a talented programmer to write code that others (or even the dev himself) can maintain.

Other things:

• Understand list views. They're ridiculously complicated but there are very few apps that don't need them, and I can count on one hand the number of developers in my company that I've come across that can implement them correctly.
  
  
• Model-View-Controller. If you don't know the paradigm, look it up. iOS/Objective-C does a lot better job of lending itself to the paradigm naturally, but that does NOT mean that it is not applicable in Java. Separating your UI from your business logic/data is crucial and will save you SO MUCH PAIN later in maintenance stages.
  
  
• Understand the Activity lifecycle. Re-read the documentation and experiment until you understand its ins-and-outs.
  
  
• Never use hardcoded strings. They're a nightmare to maintain and completely impossible to re-use. For Android, UI strings should go in strings.xml (this means, if text appears in your app UI, it better be a string resource). You may also opt to use them for non-UI things, but I prefer constants in well-named files.
  
  
• Understand when you need application context versus activity context. Understand the differences in the two. Use them appropriately.
  
  
• Android is open source and apps are extremely easy to unravel to their source code, so, don't be shy about pulling down someone else's app and dissecting it to figure out how they implemented that cool functionality. Google's apps especially. Obviously don't commit copyright infringement, but a good programmer knows when to write from the ground up and when to not reinvent the wheel.
  
  
• If you're passing information between activities, use Parcelable, or the Android Gods will smite thee. NOT serializable.
  
  
• Utilize Android's helper classes. Did you know they have a TextUtils class? It is great for String functions (like checking if a string is null or "" with isEmpty();).

Kotlin in Action seems to be the best reviewed on Amazon. I believe that anything specific to Android and Kotlin is not necessary since they're separate things that will convert pretty seamlessly. As for learning Kotlin, I'd recommend the Kotlin reference and good ol' google for any questions you might have. For a tutorial type series, Kotlin koans seems to be the best bet.

I personally came from Java then Swift within the last year. Kotlin so far has just been trial and error but not terribly difficult. If you want to buy a book to help with Kotlin, I'd do the koans series then buy something for functional programming. Possibly Functional Programming in Scala or the Java book from the same publisher. I've read a lot on functional programming and some stuff on lambda calculus. Outside of picking up haskell, just programming it the best you can and learning some of the basics from something like the funfunfunction series then build from there. Books can tell you theory but program design comes from experience.

EDIT: One thing that hasn't been inherently obvious so far was lambda expressions in Android. They seem like a powerful way to get things done effectively. Make sure you're using them when it seems appropriate.

You can start out with some of the New Boston Android Tutorials - http://www.youtube.com/playlist?list=PL3D7BFF1DDBDAAFE5

The best way to learn is to pick a project and see it through to fruition. Go with something simple but not too simple, I'd recommend trying to make your own clone of this tip calculator. Don't just make it kind-of work, get it to where you would be proud to release it.

If you are completely new to programming it will be slow going at first, but there is no better time to learn than now, with some google searches you can find hundreds of free online programming courses (MIT Open Courseware and UC Berkley should get you started). You can google just about any problem and find someone who has encountered it before and solved it, sites like stackoverflow have hit the mainstream with programmers and it has become far easier to disseminate and learn best practices.

Also, Code by Charles Petzold is by far the best introduction I have ever read on computing theory, it has very little to do with conventional programming though.

Shamelessly stealing from one of the Amazon reviews:
> The average person who uses a computer to surf the web or type letters has so little knowledge of the underlying technology he or she is using that it may as well be magic. Even programmers, who typically spend their days solving problems with the high-end abstractedness of object-orientation, may be more than a little unclear about what's actually going on inside the box when their compiled code is running.
Petzold attempts, and largely succeeds at, writing a book that leaves the reasonably intelligent layperson with a thorough comprehension of each layer that comprises a modern electronic computer (binary coding -> electronic representation -> transistors -> logic gates -> integrated circuits -> microprocessors -> opcodes -> assembly language -> high-level language -> applications). At times, the reader must follow along carefully, but Petzold tries to avoid needless complication.

Every project is made up of different people and they all have their own vibe. For the last 10 years, at least part of my job has been working in and managing people who work on open source. I and my team have contributed to AOSP, Eclipse, Apache, and others.

A random collection of unordered thoughts...

1. Start a dialog on their communication channel and ask if they will accept your help. Some projects aren't interested in help and just ignore external PRs. There are tons of projects that actively encourage participation.
   
2. If a project has an alpha-asshole, nothing you can do will make them better. You will always be playing in his sandbox. Yes, I'm saying he's an asshole, but his impact is immense. My advice is to learn the no-asshole rule and apply it to your own projects in the future.
   
3. If you find a project you really like but they aren't working with you, fork away. The best revenge is making a project better than the original. Not naming any names.
   
4. Learn the git workflow and how to merge, rebase, and amend. Especially if you're going to be working around the edges. The main committers aren't going to want to work around your PRs, especially if there is a lot of unnecessary commits in there that require them to manually merge.
   
5. Don't do wide-ranging changes (e.g. refactoring) without telling the main contributors. Getting in on a Monday and finding that 40% of your code base has changed is an unwelcome surprise.
   
6. Understand semantic versioning
   
7. Offer to handle release tasks. It's not code-oriented and has a lot of things to break up the monotony. Granted, it's often ignored by the devs, but if you do the job well, they will appreciate you for it.
   
8. When the time comes and you're running a project, remember what it was like to want to help. Encourage and grow your community.
   

Although, I am not a professional (currently, I graduated high school this year, and I am taking a year off before university to recover my health), from what I learned and applied, your planning should be first dependent upon how much time you have to deliver the project and the extent of communication you have with the risk holders.

Ideally, if you have a great amount of time and extent of communication, you might want to adopt a unified process model in a waterfall manner such that you do all your planning in the beginning. First, scope the project to understand what the risk holders' general objectives are for the project. Second, adapt the scope to determine the user classes for the required Android application. Third, by defining your user classes, write user cases for them. The user cases help generate required system features and processes. These processes help you generate story boards regarding how the user should execute a user case which ultimately helps you design your views. Fourth, research the software and hardware constraints in regards to implementing the system features. This step allows you to prioritize what features you will implement first and how you might test them. (Don't forget to research operating system quirks between various Android versions and the interfaces the risk holders require.) Fifth, verify with the risk holders the priority of the required system features. Sixth, begin your high-level design. The extent of this step is dependent upon the quality of the prior steps. If you have a great grasps of the requirements for the project and they are invariable to change, design your architecture and then components. UML diagrams should be used again if you have a great understanding of the project. All of the above steps regard the aspect of modelling in a software development process. I ignored any planning for quality management.

Unfortunately, you may lack time or great communication with risk holders (i.e. unresponsive feedback and continually changing requests). If so, I wouldn't follow all the steps above since it takes a while and you don't want your time to be wasted. Follow a rapid prototyping process or the agile process. I don't have much to say about them. They are nice.

Importantly, like everyone said, high-level design is very important. For my first Android application, my application's architecture and components were so poorly designed that my core logic was too coupled with my views and my components did not achieve a level of abstraction required for ease in refactoring. Thus, when it came time to implement new features or fix old features, it would take too much time.

If you have to work with databases, schema migrations can be hellish (I felt like crying in the inside when I learned about schema migrations). From the words of almighty Jake Wharton: "I hate it all. Schema migrations, content providers, content values, uri matchers, cursors, column interfaces, sql builders." Thus, do special planning if required with databases.

Some blog post I found (It seems very interesting. I haven't tried it yet): http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/

Finally, a really nice read if you ever have the time, Software Engineering: A Practitioner's Approach: http://www.amazon.ca/Software-Engineering-A-Practitioners-Approach/dp/0073375977

Please take what I typed with a grain of salt, I just started programming for Android in October, so I too am trying to find out the best practices.

To expand on the above, I would say that you definitely need to learn DS&A before you can get a job. I got lucky getting my first job because they didn't ask me any algorithms questions but trying to find a job is next to impossible if you can't answer their questions on a whiteboard.

Also, practice coding on a whiteboard/paper. I cannot stress this enough. It's amazing how many things you think you know but you realize that your IDE fixes for you/reminds you of. Simple, simple things that make you look completely silly if you don't know them during interviews. Plus, it's just a different process.

It's also quite nerve-wracking to stand in front of a white board and have people watching you write code.....so it's easy for nerves to get in the way as well...

Also, get this book:
http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X

There are plenty of other books out there as well...

Good luck!

Hey that is the million dollar question. But because software is not an engineering, actually there is no reference book on SW architecture. Certainly there are books talking about this, but usually covering only some aspects and without real application examples.

Notice that in iOS programming the system imposes a great part of the architecture, so these guys are usually less concerned. But in Android we have more freedom, and the API actually encourages really bad practices (thanks Google). Because of this we are all a bit lost. Nowadays layered architecture and MVP seems to be the most popular approach, but then again everybody produces a different implementation...

Specifically for Clean Architecture you should read its author, Robert C. Martin. AFAIK this is not covered in detail in his books. You can read this blog post and watch this video. Other designs usually coming up in conferences are the Onion Architecture and the Hexagonal Architecture. But make no mistake: there's no route map on how to implement any of those, and examples claiming to follow this or that approach are usually not written by the authors of the architecture.


For DDD there is a very good book by Scott Millet with actual examples. But this style is meant for large enterprise backend apps, and the author himself advices against using is in small apps. So I'd say it is overkill for Android, but of course you could reuse some concepts successfully.


Theres also Software Architecture in Practice 3rd, but having read the 2nd edition I can tell you this is just smoke.


Probably best book to date is Fowler's but this is more a patterns compilation than an architecture guide.

Here's a rough outline, from high level to low(ish):

• Fundamentals of Object Oriented Programming. Understand basic concepts like inheritance and encapsulation and why you'd use them. Any book with these words in the title/subtitle should be able to get you the basics, pull a highly-rated book off Amazon for recommendations.
  
  
• (This is optional but highly recommended) Learn basic design patterns such as those presented in the Gang of Four book. These aren't required for writing Android apps but the more you understand about patterns the more it'll help you later on. You don't need to master this stuff at the outset so just read at your leisure.
  
  
• Learn Eclipse. It's a big subject and for seasoned veterans the various components can be confusing, but you should know how to use an Integrated Development Environment regardless.
  
  
• Follow the tutorials that VersalEszett mentioned.
  
  Extra Credit
  
• Get an account on Github and understand how Git works. It's free unless you want private repos. Google around, find android development projects that are public, clone the repos and walk through the code - retype it line by line if you need to. Try to figure out why things are broken out the way they are.
  
  That will get you started but there's tons more. The best thing you can do is write code and read code and be patient.

Although old, this book does a very good job explaining the Android architecture https://www.amazon.com/Embedded-Android-Porting-Extending-Customizing/dp/1449308295

Given it was written for Android 4, it doesn't have all the new Treble staff (the basis are still the same, so I think it's still worth reading), but the author has a set of slides that you can read after the book to get the recent changes: https://www.slideshare.net/opersys/presentations

​

Another useful book is https://www.amazon.com/Embedded-Programming-Android-Bringing-Scratch/dp/0134030001 . This one focuses more on getting AOSP running on a new device, and not that much in its internals or customization.

​

Two newer books I have recently found (although I haven't had time to read them) are https://www.amazon.com/Android-System-Programming-customizing-debugging/dp/178712536X (same author as the previous one, content mostly related to building the kernel and getting AOSP running in a new device/emulator) and https://www.amazon.com/Learning-Embedded-Android-N-Programming-ebook/dp/B01841W9AU

They are still pre-treble, but they are probably still useful.

​

Besides those, if you want something more related to internals and not so much on how to "get the source code and build AOSP", you could check https://www.amazon.com/Android-Security-Internals-Depth-Architecture/dp/1593275811 and https://www.amazon.com/Android-Hackers-Handbook-Joshua-Drake/dp/111860864X

I'm also a newbie when it comes to Android programming, however I'd like to jump into it. I have a bit of a background in C++, but Java is entirely new to me.

I just purchased two books on Amazon for Java and Android programming.

http://www.amazon.com/gp/product/0672334445

http://www.amazon.com/gp/product/0672335743

Always interested in learning with others. Just let me know. :)

I agree - seems like a lack of direction is what hinders you, rather than a tech choice. I would recommend reading the following "bibles" of product development

The Lean Startup

https://www.amazon.com/dp/B004J4XGN6/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

​

Inspired

https://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408

​

These books are very accessible and will get you up to speed really quickly.

A middle ground is to have the developers write the Robot DSL and you write the tests using the DSL. It sounds nice, but not sure how many successes there have been with this approach. For more information:

https://jakewharton.com/testing-robots/

A book on Espresso from QA (not developer) perspective:

https://www.amazon.com/Android-Espresso-Revealed-Writing-Automated/dp/1484243145

What books can help you expand your knowledge of design patterns?

• Head First Design Patterns
  
• Gang of Four Design Patterns Book
  
  The second one (GoF book) is the defacto standard, but unfortunately, it's also a cure for insomnia. The first one is much more entertaining.

If you enjoyed the Head First experience, you should proceed to Head First Software Development which does cover this topic.

Strictly in order.

Head First Programming
Head First Java
Effective Java
Head First Design Patterns
Head First Software Development
<http://developer.android.com/training/index.html>

You are welcome!

Hey, want to provide an update. Just received an email from Amazon, where they said, that despite one device had issues with my app, it's now live (https://www.amazon.com/gp/product/B06XPNXKZ2)
It took some time, but they finally accepted it.

I liked this one https://www.amazon.com/Android-Application-Development-Hours-Yourself/dp/0672334445

Grady Booch
http://www.amazon.com/gp/aw/d/020189551X/ref=pd_aw_sbs_14_2?ie=UTF8&dpID=51-uo4HUPCL&dpSrc=sims&preST=_AC_UL100_SR100%2C100_&refRID=110KGH6M22KWAJHKWZ5F

Eric Evans
http://www.amazon.com/Domain-Driven-Design-Tackling--Software/dp/0321125215

Martin Fowler
http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420