Open Talk: A Whirlwind Tour of Gradle for Android with Mark Murphy, June 17

A Whirlwind Tour of Gradle for Android

The Android tools team has been hard at work developing an Android plugin for the Gradle build system, with an eye towards Gradle for Android replacing the venerable Ant for automated builds. Gradle for Android is also used by Android Studio, the new Android IDE, for its builds. In this presentation, we will explore what Gradle for Android is, what problems it solves, how to get started playing with Gradle for Android, and how to take advantage of some of its basic features. Attendees will leave with a better understanding of why Gradle for Android is important for all Android developers in 2014 and beyond.

About the presenters

Mark Murphy is the founder of CommonsWare and the author of The Busy Coder’s Guide to Android Development. He is active in supporting the Android developer community, from answering questions on StackOverflow to publishing sample code and reusable components as open source.

A three-time entrepreneur, his experience ranges from consulting on open source and collaborative development for the Fortune 500 to application development on just about anything smaller than a mainframe. He has been a software developer for nearly three decades, from the TRS-80 to the latest crop of mobile devices. A polished speaker, Mr. Murphy has delivered conference presentations and training sessions on a wide array of topics internationally.

RSVP Here.

Open Talk: Making Sense of JavaScript Using Backbone & RequireJS, May 27th

Making Sense of JavaScript Using Backbone & Requirejs

JavaScript can often feel like a free-for-all. The past few years have brought us amazing tools such as jQuery, Backbone, Requirejs, and more, which we can leverage to bring some sanity to our front-end applications.

This talk will set you on a path you may not have thought possible with JavaScript – clean, well-organized code, separated into views, data models, and other modules where dependencies are clearly defined and laid out in front of you. You don’t need to be a JavaScript “ninja” to start kicking serious butt on the front-end. Just an hour or two of dedicated training.”

About the presenters

Corky Brown – Corky has been doing web development for nearly a decade and is closing in on his eighth year at MeetMe. During his career, he’s worked on both the front and back-ends of web applications, but has in recent years focused primarily on building JavaScript applications using tools such as Backbone, RequireJS, and Bootstrap.

RSVP here.

Android Debug Bridge (ADB) command scripting

The Android Debug Bridge (ADB) is a useful tool for testing and debugging, though it can be cumbersome to use given its broad set of options. For example, testing an app might require frequent authentication, and just sending the username with adb looks like this:

Command aliases can simplify this. In bash, these can be added to the startup script, such as .bashrc:

Now the username can be passed by simply typing:

Windows users can do something similar using Doskey.

The password could be sent using a similar alias:

Since other text might be sent, and those aliases can be chained together, you could setup the following:

Next, add in some keyevents for navigating between the fields:

Now, the whole login flow can be performed using a single command, such as applogin:

This can be handy for simple and frequent app interaction while testing. I use scripts such as these to navigate through initial activities during a fresh app launch to get me to the point where I need to test or debug quickly.

A similar approach to all of this is to use monkeyrunner, or continuing down that route, testing using something like calabash, but for something quick, I find that this fits the bill.

Here is a larger set of adb option aliases, comprising my basic day to day needs:



Do you find this sort of work interesting? Do you love quaint Bucks County Pennsylvania? Are you an amazing Android Developer? Then we would love to hear from you!

Android Image Credit: Copyright Pinada, CC BY-ND 3.0

Upcoming Meetup: How Not To Do Postgres Connection Pooling

In May 2014, MeetMe engineers will be presenting a talk, Lessons Learned: How Not To Do Postgres Connection Pooling, for the New York City PostgreSQL User Group. In this talk, we’ll discuss real-world connection management issues encountered while running Postgres as the primary database for a top-ten social network. This includes drilling into mistakes commonly made in regard to Postgres connection management, the disasters that follow, and how to do things properly. An overview of topics involved are as follows:

  • Postgres connection management
  • Performance
  • Queueing
  • Limitations
  • PGBouncer usage and configuration

The talk, which will be held at 6:30 PM on Wednesday, May 14, 2014 and hosted at the Yodle offices, will be presented by long-time MeetMe engineers and Postgres contributors Jonah H. Harris and Michael Glaesemann, respectively the VP of Architecture and Sr. Data Architect. If you’d like to attend, please join the MeetUp! You can also get the ICS file here: New York PostgreSQL User Group Meetup.

Keep your classes and methods as small as possible

I have a friend who recently started a new programming job and he kept complaining that his code was being rejected. Most of the time it was because his methods and classes were too long; it didn’t make sense to him why he needed more classes or methods to accomplish something simple. He felt that it would make his code more complex and harder to debug instead of just keeping it only one class and a couple of methods at most.

This is an advice that we programmers tend to give a lot, but most of the time we don’t really explain why is a good advice. Some people take it to far and I see why you would think a class with too many methods will be more complicated than one with very few. In the interest of keeping things simple, I won’t go into the details of SRP ( Single Responsibility Principle ) and encapsulation, but a basic definition would be that a class or method should be responsible for one thing and you can change it, without affecting the other parts of the system.

Let’s say that we need to send an email with some data when a user is older than 18. The data will be read from a config file. To keep it short we’ll assume that the email sender and config are in different classes.

Seems simple and easy to read, but if you take a closer look, its not very testable since we can only test on user age and not if the config is empty.

So we need to refactor the class by taking out the read config logic into its own method.

By doing this, we now can test both conditions by stubbing the getValuesFromConfig method and defining our own value. This allows us to check that the config is returned as an array as well.

But even though this improves things, the class is still not very maintainable.  What if the action now depends on the user being a certain age, gender, or country? We could create a lot of methods to validate each thing, but our class would do too much.  Don’t forget SRP, so lets create another class to handle this.

Now we can write separate tests as well and know that if we change our validations we will not affect the other class and viceversa.

Quick note, when writing these kind of validators, I like to use exceptions in the private methods instead of returning true or false.  That way I don’t have to write one big if and I can take advantage of the @expectException notation. This leads to cleaner tests.

Now the code is looking a lot better.

But wait! There’s more. We still have not completely solved our testable problem. We moved one dependency into its own method but we still have two left that will cause problems.  We can create new methods for them, but remember when I told you that some people take it too far with creating a lot of methods?

Dependency Injection (DI) to the rescue!

Instead of the class getting the object it needs, you provide the class with the other objects they’ll use by “injecting” it, just like the name says. One of the advantages of using DI is that it makes our tests a lot easier, instead of mocking our config object like we did above, we can create an empty config object and use that for out tests. For this, always prefer interfaces over direct classes, it will make your code cleaner and easier to maintain since no matter what object is passed along you’ll know that it will have the methods it needs.

Dependencies can be injected in the constructor or with setter methods, lets use the constructor

Now we can write our tests and be sure we won’t be using production data

So in the end we took 20 lines of code and turned them into 67 lines ( 2 classes, not counting interfaces ), but I hope that you see that by taking “simple” classes and breaking them into smaller ones, you end up with code that’s flexible to change, easier to debug, and cleaner.