How to get started with Android development – Basic structure

andro02In a previous article, I wrote about how you can launch your first Android application from the samples provided with Android Studio. Now that you’ve had a chance to poke around a few samples, I’m going to tell you a bit about the basic structure of an Android application.

A good place to start understanding an application is the manifest. The AndroidManifest.xml file links all the parts of an Android application together, including:

  • The activities contained in your application,
  • The theme you use,
  • The name of the application and its icon on the main screen,
  • The permission the application must request to run.

Activities and the java folder

The Java code of your application lives in the java folder. The first class you’ll create is a Activity class, which is the main building block of all Android applications. An activity is a full screen window in which all your code will run. Each activity has it own life cycle which starts when it’s first launched and last until it is finally destroyed.

The user navigates between different activities in your application: the back button of the device closes the current activity by default and goes back to the previous one. If the user closes the first activity of your application, he’ll go back to the application that was previously open, if any. You can also launch other applications (with their own activities) using intents. You can use this to request an application that can send an email or play music, and the installed applications that can manage this will be displayed to the user.

The activity life cycle can be affected by events outside your control: for example, if a phone call comes in, your current activity (so your application) will be paused. Each activity has a layout associated with it that describes how controls that are displayed, and the activities are declared in the AndroidManifest.xml file.

Unfortunately, the fact that the activity is bound pretty strongly to the navigation AND to the user interface/layout makes it hard to separate the business logic and the display logic properly. You can create a usable Android application with only a .java file with an Activity class, but eventually you’ll want to move on to a better architecture. There are some patterns out there that can help you do this, but for your first application you should stick with this and avoid introducing additional complexity.

Resources

Resources are everything that your application needs that is not Java code, such as layouts, strings, images and other constants. The Android API uses XML for most resources. The res folder contains all the resources of your application, such as:

  • XML layouts for each activity and component in the layout folder, styles in the values\styles.xml and images in the drawable folders. Layouts in Android are inspired by HTML/CSS, so if you’ve ever done some web development you’ll feel right at home pretty soon.
  • All the strings used in your application in values\strings.xml. You can hardcode them in the layouts, but if you ever need to translate your application you’ll be glad you put them all in one place to get started with.
  • Menus for your application are defined in the menu folder.

See the other articles in the series here

Writing a book: how to work on many projects

After quite a bit of pondering, writing and editing, I shipped the Learning as a Software Developer book last week. The whole process took about 6 months to complete, so I had time to experiment with a few ways to work. During that time, it was important for me to keep the blog going and still have time for technical learning and my various homestead-y hobbies. So, in that case, I was in for a marathon, not a sprint.

Spoiler: making a commitment to write regularly was the best way to make progress.

I’ve also tried a batching approach to the problem. The idea was to write a few blog posts in advance the first week, then spend the next week working on the book, and finally do a bit of technical learning. It was working decently at first and I WAS able to batch a few posts in advance, but then life happened and I was only able to write a little bit for the book before having to go back to blog posts. Fail!

Making sure I’d work a bit on everything each week was the best way to make sure I’d keep moving forward. It kept everything fresh in my mind, so I had less catching up to do to go back into the flow and start writing. To limit context switches, I’d pick ONE thing to work on every night instead of jumping from task to task.

important-writingI’m aware this makes me less effective than batching, and that it takes more time to complete some projects, but this way I don’t lose steam and burn out. Right now, I’m living in manager space and not in maker space: I don’t have time to focus intensely on a project for hours every day, so I have to sprinkle important projects here and there to make sure they get done. If I space out working on each project too much, I’ll wake up 6 months later without having published a new blog post or written a newsletter.

Relating to this, I also had to hone my ability to get to work immediately (or at least faster) since I’m working during the gaps in my day. I only have a block of a few uninterrupted hours in the weekend if I’m lucky, so I can’t lose 2 hours getting started every time.

The key here is to have a task primed and ready to go, or at least a well-defined process. For example, to write a blog post, I generally write a draft in one go, and then edit the next time, so I’m either starting a new blog post or completing one.

Finally, what helped me is that all those tasks are similar enough to fall into the same habit. I changed my blogging habit to a habit of writing and coding using the same cues and rewards, so I’ve not lost a habit that took some work to build. It took quite a while to ship everything this way, but in the end it was worthwhile and allowed me to ship the first version of the book to you.

Get my Learning as a Software Developer guide

You became a software developer because you love programming and couldn’t believe people got paid to do this. You first learned programming at school, where somebody else dictated what you should do and learn. After you finished your degree, you finally got a job, and you kept learning fast about building software and your industry until you were up to speed.

But now that you’ve settled into a routine at your job, what is the next step? How do you keep learning and growing as a software developer? Nobody will tell you what you should learn next anymore: you’re on your own. But you’re stuck on an endless plateau, and can’t see a way out of it. You maintain the same old legacy application and fix routine bugs day in, day out, since you’re too valuable in your current role. You can feel your passion and motivation dwindling dangerously fast, but you don’t know what do to about it.

Even worse, you’re falling behind, slowly crushed by the huge treadmill of new frameworks and languages. All those kids fresh out of school are all about React, Rust and NodeJS, while you were learning Java only a few short years ago. You know you can learn new tools without waiting for permission but every time you tried it a fancier tool came out shortly after, making your knowledge obsolete. Silverlight anyone?
Treadmill
You could switch jobs, leaving your crummy legacy code behind to solve new problems. It’s a valid strategy if you can’t take it anymore, and it’ll work for a time. Unfortunately, once you’re over the initial learning phase, you’re going to repeat the same pattern. If you start over as a junior every few years, you’re never going to improve your craft.

But what if you could take control and grow without waiting for a boss to tell you what to do? What if you could keep learning, stay sharp and become passionate about software development once again? You’ll have skills you’re proud of, work on cool projects and be confident in your knowledge and expertise.

If you try to keep up with all the new frameworks and tools you come across on Hacker News, staying up to date is an overwhelming burden. Fortunately, you don’t have to do it all: you can choose the skills to invest in to get the best out of your limited learning time and grow as a software developer.

Understand how to choose the best skills to learn with the Learning as a software developer guide and workbook. You will :

  • Learn to see the big picture, understand where you are and what motivates you.
  • Plan which skills you need to learn to reach your goals.
  • Choose what you’ll learn next deliberately instead of jumping on the latest bandwagon.
  • Pick up new skills with ease using the right techniques and habits.

Grab a cup of coffee and the Learning as a software developer package, and get to work becoming the best software developer you can be!

Purchase now at https://sellfy.com/p/ibXx/.