Touch Lab Blog

March 2014 Android Meetup - Android and Design

image

You know it’s going to be a great meetup when the pizza runs out before the talks even start. On Wednesday night we hosted our “Android and Design” meetup at Tumblr and had a huge turnout of about 200 members. We were treated to exceptional pizza (the sausage one was bangin’), Budweiser (Tumblr’s “favorite”) and a cozy space with many picturesque picnic tables.

Touch Lab president and meetup organizer Kevin Galligan started the night off with announcements. Space Apps, which Touch Lab is sponsoring, will be happening April 20-21 in New York City. It’s a tech development/problem solving event that takes place in over 75 cities worldwide.

We also announced DroidconNYC. Droidcon is the largest international Android convention spanning 15 cities and counting, consisting of barcamp, hackathon and conference/workshops. Droidcon’s main flagships are Berlin and London, and the team here at Touch Lab will be organizing DroidconNYC, the first one in the USA! We’re looking for volunteers, sponsors, venue suggestions and contacts. If you’re interested in supporting Space Apps and/or DroidconNYC, get in touch with us.

Kevin also talked about app demos. If you have an app that you’d like to demo at our next meetup, get in touch with us. We’ll install your app on our device and at the end of the meetup, you’ll have two minutes to demo your app to everyone. Our host at Tumblr, Chris Haseman, then gave a warm welcome to the crowd and talked about their awesome Android team (hint: they’re hiring).

image

Dave Redding and Walter Dziemianczyk, our very own developers at Touch Lab, started the talks off with their topic, hidden patterns in Android. They gave overviews on Gaussian blur, pull to refresh and Google+ share and how they’re UI/UX features that aren’t in design docs but are widely used. Their talk is here.  

image

Kevin Grant, Android engineer at Tumblr, gave his comedic take on Android design and ways to rethink how you approach design. His talk is here. Don’t you love it when your designer asks, “How hard would it be to do this?” His motto? “Say yes!”

image

Deniz Veli and Paul Lau then delivered a detailed talk about end-to-end Android design at Etsy. Paul showed slides of screen sizes that he designs for, and also sample markups to demonstrate how devs and designers collaborate at Etsy. Their talk is here. After Q&A and great design insight from our speakers, we mixed and mingled and moved the party to Lillie’s for drinks and more conversation.

Join us next month at StackExchange for Mark Murphy’s talk. We’d like to give preference to Android developers since this will fill up fast, so please get in touch with me and clarify that you’re a dev if you’d like to be added!

See you next month,

Olivia
Operations, Touch Lab
Co-organizer, NY Android Developers Meetup

February 2014 Android Meetup – Android and Devices

image
A very wise developer once said, “Coding is fun, but sandwiches are better.” Thanks to Google and our amazing speakers at our “Android and Devices” meetup Wednesday, we had bits of both. Early birds started arriving around 6pm and helped themselves to an impressive array of sandwiches, soda, chips and brownies.
While everyone mingled, I went around with Mike, who graciously helped me give out raffle tickets for two Spherosrobotic gaming balls that you connect and control with your phone or tablet. To kick off the meetup, Kevin welcomed the group with a warm (and as usual, comedic) intro. For our avid tweeters, he shared our new meetup Twitter account, @NYAndroidMeetupand our hashtag #androidnyc. He also introduced me! If you have questions or suggestions about meetup logistics, please let me know - we’re always looking for people to present and new topics.
David Haddad, Founder/CEO of Open mHealth was our first speaker and talked about why open software architecture is needed to make sense of the array of data coming from health apps and devices. He showed a real-life example of a patient who had post-traumatic stress disorder. A health app showed his decreased texting activity to his wife and helped doctors realize that he was becoming more distant as a result of PTSD.
 
Inder Singh, Founder/CEO of Kinsa Health demonstrated the Kinsa thermometer on an Android device with his marketing guru Erin Koehler. They aim to map the spread of diseases in real-time with their smart thermometer, while keeping it fun and comfortable for kids. Inder also discussed the pros of working with Android, such as being able to use the audio jack for input/out simultaneously - something you can’t do on iOS.
 
Izzy Johnston, Lead Android Developer at Quirky bravely took the stage without a PowerPoint presentation, but she didn’t need it! She talked about Quirky’s mission to bring new inventions into the market through voting from their online community and their own product design team. She also connected her Pebble watch via bluetooth and switched on a lightbulb nearby!
Last but not least, Dario Laverde, Developer Evangelist, gave his intro talk about working with the Glass API and what’s in store. He also showed the array of functions that Glass is capable of, including “read my mind” and “play a game.”
image

Our curious audience had many questions about the various devices after - I’m glad our presentations didn’t run over so we had time for all of them! Izzy then helped us select two lucky winners of the Spheros. Before the night ended, we wanted to try a new thing we learned from Larry Legend from the NY iOS Developer meetup. We gave developers a chance to talk about any open source projects they’re working on, connect with job leads, etc. Kevin then thanked everyone for coming, and a few energetic meetup attendees joined our Touch Lab team for drinks at 675 bar afterwards.

 
Thanks to Roman at Google for coordinating, and to our speakers! Save the dates for our upcoming meetups:
  • March 12 at Tumblr - The topic is Design
  • April 16 at StackExchange with Mark Murphy, who will talk about the next billion Android users
 
 
See you in March,
Olivia
Operations, Touch Lab
Co-organizer, NY Android Developers Meetup
image

image

image

January 2014 Android Meetup - New Year’s Resolutions

image

New years resolutions… a fad that’s gone by February or one that will stick around? Hopefully it’s the latter for the 100+ attendees who came out for our New Years resolutions meetup on Wednesday! To ring in 2014 the right way, we wanted to talk about things that we should be doing, but don’t. As our meetup’s founder and Touch Lab President Kevin said, it’s time to make some resolutions (or at least watch people talk about them). 

image

Our gracious hosts at The New York Times kicked off the meetup with a warm welcome from Kate, their mobile product manager, and Howard, their lead developer. After Kevin’s housekeeping announcements, talks started with Paul Dupuy up first; he showed everyone how his product Duologue helps you compare app screenshots with mockups, track bugs and comment. Kevin spoke about IDE’s (Integrated Development Environments), especially Android Studio, and Kevin Schultz from Lua Technologies talked about more advanced Gradle features. Dave Redding and Matt Davis, developers at Touch Lab, spoke about using Robotium vs. Espresso. The night ended with questions from the audience and more mingling. 
image
Thanks to The New York Times for their hard work and the amazing space, and to our speakers! As for upcoming meetups, here’s 3, save the dates:
  • February 12 at Google (connected devices including Glass) 
  • March 12 at Tumblr (design)
  • April 16 at StackExchange with Mark Murphy, who will talk about the next billion Android users.

image

Until next time!
Olivia
Operations, Touch Lab
Co-organizer, NY Android Developers Meetup

image

If you’re not subscribed to our meetup announcements, make sure you turn them on here.

Our very own Dave Redding speaking at the University of Scranton

At Touch Lab we’re not shy about telling everyone how amazing our team is and we just love it when other organizations recognize how great our people are. Today (November 19th, 2013) Dave Redding, one of our Senior Android Developers, is speaking to the Association for Computing Machinery at his alma mater, the University of Scranton about his ongoing experience with startups, programming and mobile in NYC.

We pulled Dave away from his screen for a few minutes to find out a little more about this talk.

So how’d you end up with this speaking gig?

My buddy Joe still works at the university and the professor in charge of ACM was looking for presenters. Joe suggested me and the professor remembered me and reached out (Dave did his undergrad and grad work there and even taught Computer Literacy for two years).

Can you give us a few highlights from the talk?

I’m going to talk to them about my journey from university to now. My first job was as the lead Android Developer building the USPS app in a big organization. After that experience I realized that I had ambitions of greater things and found Touch Lab on Stack Overflow. They were a smaller, tight knit firm where I wouldn’t get lost in the clutter. I wanted to be a better programmer, this was the place to do that.

What do you hope the students are going to get from it?

That programming for Android doesn’t have to be difficult if you know what you’re doing. There are ways to solve the big problems and you can reach out to the open source community for help with those like syncing, fragmentation, user experience.

Give one piece of advice to today’s undergrads that you wish you knew back then.

Be more active in the open source community. As an undergrad I didn’t feel I was qualified and I was scared to jump in. The world is not filled with bad people, people are wiling to help you if you just expose yourself a little bit.

Hacking the NY Android Developers Meetup

image

On the Touch Lab blog last week we shared that the New York Android Developers Meetup is getting to be too much for awesome Kevin to handle alone, and that we’re looking for a (paid) Part Time Event Coordinator to help make the meetup bigger and badder than ever. While we can’t wait to get the right person on board and let them loose, there’s another equally important thing to consider. What does the community want to see happen with the Android Developers Meetup?

At last night’s meetup we had two great presentations on a collection of image download/cache tools, one by our very own Dave Redding and the other by Matt Spitz. After the demos we took advantage of the fact that we had some of the smartest minds in New York in the room and we hacked the meetup.

Read more

8 tips for building a badass offline app

image

This is Part 3 of 3 in a series on Offline Connectivity.
Read Part 1: No Connection? Big Problem
Read Part 2: Offline functionality is a no brainer (and how Twitter dropped the ball)
————————————————————————————————————

Most developers hone their coding skills by learning how to build web apps. On the web, you’re always connected: you can submit data instantly and check out recent changes with a simple refresh. And if something goes horribly wrong, your user will be able to detect it right away.

Not so with mobile.

Despite the fact that it’s impossible for mobile apps to be constantly connected to the Internet, many developers design them as if they will be. Even when building in valuable offline support would be easy, dev teams often don’t even think about it.

Here are eight tips for building a smart mobile app:

1. Assume your app will usually be offline

For your app to be the best it can be, the wise thing to do is is build it with the assumption that it will be offline most of the time.

Think about it: just because your phone thinks its online, does that mean your request will succeed? What if your device is connected to WiFi, but the router isn’t? What if your server is down? What if you’re in that strange netherworld where the phone thinks its online, but you just got in the elevator (ie “softline”)? Etc.

Lots of things can go wrong. It’s better to think like you’re always offline, with an occasional chance to talk to your server. Stop talking about offline “mode.”

2. Work smart

Does your entire app need to work offline? Probably not. Make a list of all features and estimate a) how important that feature is, and b) how hard it’ll be to support it offline. To maximize your efficiency, pick the good stuff and skip the rest.

3. Do the bare minimum

If you want your app to keep user adds/edits (and you should!), but you don’t want to implement a full db table sync, you can simply push the add/edit command into the queue and let it process later when there’s a connection.

Basically, the json you were going to send to the server gets stored in the command before it can be sent. The benefit is that the user won’t lose data entered offline, and you’ll keep your logic to a minimum (full 2-way sync is significantly harder than 1-way, in either direction). It’s a bit “ugly,” but will keep the users happy. Its also a lot cheaper to implement.

4. Choose an offline sync method

There are two basic methods of syncing: state-based (SB), and command-based (CB). (For a really detailed explanation, check out our post on Data Synchronization.)

SB and CB are conceptually the same, except that SB requires you to recreate the list of commands yourself from the “state” of the data, while with CB, you explicitly record the commands as you go. CB also lets you do stuff that isn’t in the DB, like upload images.

SB queries the database to see what needs to be synced. This generally manifests as a “dirty” flag on the table in the form of an “updated” timestamp. The concept is simple, but the process can become a huge pain as your DB gets more complex. Especially with foreign key relations.

CB, on the other hand, has these operations explicitly added to it from your app. If you save an account entry, for example, the command to send it to the server is recorded in the CB queue. This means they’ll run the moment your app detects a friendly network condition. CB’s complexity grows more linearly with DB complexity than SB. (Touch Lab wrote a CB command queue called Superbus —I recommend you try it! There’s a simplified v2 in the works.)

5. Understand the difference between temporary and permanent issues

Unlike most web app errors, mobile “headless syncing” errors aren’t immediately apparent to the user, which means they might not get fixed.

This means it’s critical to understand the difference between temporary and permanent issues. Temporary issues usually spring from having no internet connection, or a down server. (In Android, you also *maybe* have to worry about the SD card being removed.)

Pretty much everything else is a permanent issue, and your app needs to be equipped to deal with them. At a minimum, build in messages that will tell your user what’s up when something goes wrong. You can also give them a chance to resubmit. Whatever you do, don’t just “drop” the command. Nothing gets your app a 1 star review faster than losing your user’s precious data!

I’ve noticed that new developers tend to lean towards assuming an issue is temporary, but this is dangerous. (Read the Superbus docs.) If you’re not careful, you can wedge your app permanently, as the queue will try your command, “fail” temporarily, and shut down to wait for more favorable conditions — which will never come.

That, of course, assumes you’re using our queue process, or something similar. Even if you roll your own, though, think about it. You have to be VERY careful with error handling. What happens when there’s an error? Do you skip the update? Can you? Was it really a problem, or was the server down?

One example from Touch Lab: we implemented an app with the first version of the queue, interpreting all IOException instances as network issues. This, of course, was wrong. There ended up being an image upload command that was trying to send an image that had been deleted.

(Whoops. Life would be much easier if there was ShittyNetworkException, but there isn’t.)

Additionally, some server APIs use http codes well, but many will return 200 regardless of what happened and push actual error conditions into custom fields. This makes identifying errors more difficult — you may “finish” the command when you really had a data problem.

6. Don’t wedge your app

This applies directly to people using the Superbus queue, but in theory it goes for everybody.

You need to discern what exceptions are temporary in nature from permanent, and you need to keep temporary sync events in a “pending” state. In CB, that means leaving them in the queue. In SB, that means leaving your “dirty” flag dirty.

Also, unless you have a really loose schema, you need to process things is some form of temporal order, or everybody will get upset (either your users, because something from five days ago just came in, or your data, because of foreign keys).

The big danger here is wedging your app. Permanently. If you keep thinking an exception is temporary, when its really something that’ll never go away, you’ll leave the app in a never ending state of incomplete sync. Nothing that comes after the poison event will ever process.

In Superbus, there’s a CommandPurgePolicy that you can implement to force something out of the queue. If something has been processing for a while, you can dump it. Sounds nice, but this is MUCH harder to do well than you think. How long before you dump it? Under what conditions? Also, nothing else processes while this is being decided.

The default policy in Superbus is TransientMethuselahCommandPurgePolicy — because I like funny class names, and I want to make sure you understand that if you don’t do this properly, the command will live forever.

7. Opt for multiple ID values

If you’re a sane person, you use numeric IDs on your tables. When I first started doing sync on mobile, I tried to keep one “id.” Like a concerned parent, all I can say is: don’t do this. You’ll regret it later. For two-way sync entities, have a “localId” and a “serverId.” It’s just a lot easier to manage. (Say you create a value, then go back in to edit it while your sync is processing. You’ll either crash or create a duplicate entity.)

8. Understand data storage vs Id storage

When you add/edit an entity, and create a command to push the data, you can either keep a reference to its local id, or create a json dump. There are arguments for each — and to be totally honest, I flip flop periodically.

Keeping the actual data means you can send things in their actual order. If you only push half of the commands before losing your connection, a remote client should have a reasonably coherent version of the “truth” because the remote data was added in order. You can also do update “slices,” which only update certain fields, rather than whole entities, which is very valuable if multiple users are making edits.

Id references, on the other hand, are generally easier to implement if it’s not super critical to have your updates process in order. You can “collapse” them, so multiple edits are contained in one “command.” And if you upgrade your db schema, the data in the app queue isn’t “stale.”

However — and this is critically important — if you’re using id storage and your tables reference each other, give your “create” commands a higher priority. This makes for a bit of a temporal issue, as it’ll run all of your creates before your updates — but if you run an update and set a foreign reference to an entity that doesn’t exist yet, you’ll be having a bad day. You can mostly avoid this problem by slotting all of your adds first, although there are times when that won’t work right in all cases. Think defensively about how things will process in the real world.

Coming Soon, Touch Lab’s First eBook!!

——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let’s chat about your project, get in touch.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

Offline functionality is a no brainer (and how Twitter dropped the ball)

image

This is Part 2 of 3 in a series on Offline Connectivity.
Read Part 1: No Connection? Big Problem
Read Part 3:8 Tips For Building a Badass Offline App
————————————————————————————————————

As a startup founder, I get it: it’s a lot easier to compete in an existing market than one that doesn’t yet exist.

But as a developer, my goal is to build apps with the highest level of functionality possible.

In Touch Lab’s grand vision for the future, android users will be able to interact fully with their favorite apps whether or not they’re connected to the Internet (except for features that specifically require a connection).

Twitter: just … why?

Twitter’s Android app is a prime example of what can go wrong when developers turn a blind eye to offline functionality. If your tweet doesn’t publish (say, because of a failed Internet connection), it automatically gets filed into a “drafts” folder. Where it goes to die, basically.

In addition to users being notified only once about their failed tweet, navigating to the “drafts” folder is like finding a needle in a haystack — a haystack positioned at the end of a 10-mile maze. From a developer standpoint, it’s really, really easy to program the app so that the tweet is automatically queued up when a connection returns, so I have no idea why Twitter doesn’t do this — it’s incredibly frustrating from a user’s perspective.

image

Take this example and multiply it by a bajillion, and you have the general sorry state of Android apps today.

UX to the rescue

Fortunately, the UX (user experience) community has done a great job recently of convincing people that the user’s perspective is actually important.  A few years ago, UX was new and mysterious, but now companies, from Apple to hot new startups, pour big bucks into it because they understand that users respond to — and eventually adopt — apps and platforms that just work.

Although we generally think of UX as the practice of “figuring out where the buttons go,” the manner in which your app behaves in adverse conditions will increasingly be a part of the overall experience the farther we move away from the desk.

Very often, developers frame the offline debate as a black and white issue. It’s either “we support offline,” or “we don’t, because it would take a massive rewrite.” The reality, however, lies somewhere in the middle.

 

——————————————————————

Looking for a great team of focused Android experts to bring your idea to life? We do one thing: make Android apps. Keeping that focus means we can do things the right way. Let’s chat about your project, get in touch.

——————————————————————

Are you one of the best Android developers out there who likes solving problems, working on a small, agile team and building only the best solutions? Maybe we should talk, get in touch.

We’re Hiring a Part-time Event Coordinator!

photo by Robert Quiles via Meetup App

As an Android-only dev shop, Touch Lab is proud that our founder Kevin runs the number one Android get-together in New York. With 1200+ incredible members and 26 awesome events behind us, the monthly New York Android Developers Meetup is the place where the best Android developers in the New York Tech scene (and their fans) come together.

With your help, we’re looking to make it even bigger and badder. We’re looking for a smart, friendly, and organized leader type who is passionate about New York’s tech scene and interested in event planning and business development to take the helm, manage the event and help us continue to improve the meetup.

3 reasons we’re hiring:

  1. The meetup is amazing, and with all the growth Touch Lab is experiencing, Kevin can’t always give the meetup the time it needs
  2. The Android community is amazing, and we feel a responsibility to invest in making the meetup the best it can be
  3. Our sponsors are amazing, and they want to offer value to the community; we want to help them do that in the best possible ways
  4. There’s a top-secret fourth one (it’s at the bottom)

Here’s the basics of what we’re looking for:

  • You’re an recent grad or career-changer and want to get your foot in the door of the New York Tech scene, but you’re not a developer and haven’t yet launched your first world-changing startup.
  • You’re organized. No seriously, you’re crazy organized and you really love the whole “being organized” way of life.
  • When you go to a meetup or a conference, you look around and think things like “why didn’t they get xyz company to sponsor, they would’ve been great?” and “wow, a little extra effort and they could’ve made this way more awesome by doing xyz

Sound interesting? Read the details below and then get in touch with us. By the way, it never hurts to be introduced by someone who’s a mutual friend.

Read more

Collaborate with Touch Lab and get a job at a great NYC startup

image

Over the next few months we’re rolling out a program that we’re really excited about. Select clients will be able to embed a developer with our team for the duration of their app build (and maybe beyond). They will work side by side with our team, learn, train and share knowledge with us. The client not only gets a great app, they also get a top-tier internal Android developer who’s had chance to level up their skills.

Our first group consist of developers from two of our awesome clients: TheLadders and Cover. In fact (as you might have guessed from the title), our friends at Cover are using this as a really clever recruiting tool; so if you’re a kick-ass Android developer and you want to work for a great startup (and collaborate with us), check out the post and get in touch with them right away.

——————————-

Our Embedded with Touch Lab program is not yet officially launched, but we will respond to all of you who’ve been emailing about it. Feel free to continue emailing us about it, just please understand that it may be a couple of months before we can offer a spot for your developer to apply for.

Thank You for the Feedback on the 1 Second Everyday App Release

Screen Shot 2013-08-12 at 1.11.41 PM

We have great clients and push to create the best possible Android apps for them, so on release day we always feel good about the product we’re putting into the world. That said there’s few things better than to hear that others also love what we’ve put together.

Thank you to everyone who’s downloaded the 1 Second Everyday app so far, and a special thanks to everyone who’s taken time out to rate the app, it means a lot to us and to Cesar & his team.

In addition to the users letting us know they love the app, we’re excited and grateful to get great feedback from all around the internet. Thank you for your reviews and mentions and we’ll be sure to add any additional pieces as they’re posted.