Droidcon Lisbon 2019: An Overview

Droidcon Lisbon 2019: An Overview

John Surface

This week, I attended a Droidcon event in Lisbon, Portugal. The conference itself was at the University of Lisbon, known at this time of year for bright sunshine, mild temperatures, and a unique initiation ritual for freshmen known as Praxe, which was going on all around us. Aside from realizations of how comparatively good I had it in college, the conference was a fantastic experience, both for setting and content, and for the wide array of nationalities found amongst the attendees. 

It was interesting to share ideas and gain perspective from coders who, mostly, were not American. The conference itself was eye opening, and not just because I made what I assume is the very common mistake of drinking coffee-sized portions of espresso (“These cups are so small, that’s cute! Wait, why am I vibrating?”).

Here are three takeaways from Droidcon Lisbon 2019:

Size Matters

There were at least 4 presentations that directly related to the size of APKs. More and more people are relying on smaller APKs, and with the app bundle they now have the power to receive molecularly small file sizes. As with anything, we can take this to the extreme, such as only downloading features as we need them, saving the user a good 10 MB if they don’t want a specific camera feature, for example. 

I’m not entirely convinced that users examine file size when downloading apps, and I would think this is a lot of developers effort for 10 MBs. At a certain point, it feels a little like code golf but with APK sizes. I’m sure the benefits become far more clear on large apps with many features though.

Sometimes the theory is better than practice:

I’m a math and physics nerd, so whenever there’s an opportunity to learn exactly how satellites use trilateration for my position on the globe or how hackers gain access to encrypted passwords, I perk up a lot more than I would at a slide full of code samples. 

Talks by Richard Süselbeck and Xiaoyi Li on global positioning and password security, respectively, were just such talks. They provided info general enough for almost any developer conference. This is useful because it allows developers to expand their world beyond Android studio and competently discuss exactly why they should take certain measures regarding password security or location services.

Not that I didn’t enjoy slides of code samples. One of my favorite talks was ostensibly a showing of the ADB documentation, but I found the breadth and depth of its uses fascinating, and the examples that Zhenlei Ji provided were as useful as they were funny. (Have a bug that involves scrolling a list for five minutes? Don’t do it yourself, write a shell script using ADB commands to do it for you and go get a coffee in the meantime.)

DAE Coroutine? 

The biggest, most unavoidable topic of the conference was Rx vs Coroutines. Coroutines are obviously SO hot (you know..Mugatu…see right) and several talks explored their advantages/disadvantages vs Rx. My take is as mild as the breeze coming off of the ocean in downtown Lisbon: coroutines are easier to read and better to use for more common asynchronous tasks in Android. Almost anyone at Droidcon will tell you that. Because of this, more and more people will start using them. 

The downsides of Rx are not so great as it requires switching immediately, and there’s a hefty learning curve. A few speakers acknowledged, reasonably, that it will probably be better for your business to keep using Rx if it’s already in your project.

Before hearing about Droidcon Lisbon, I would have assumed that any international event would break the bank, but this inaugural conference was affordable, possibly because of its cozy two-track size. It allowed the event to be accessible on a financial level, besides Droidcon’s stated values of inclusivity to those from all walks of life and levels of Android experience. I would encourage anyone to look at the schedule for the next few months and see if they’d like to learn more about Android in Vienna, Shanghai, or Tel Aviv, for example. Maybe I’ll see you there.

John Surface

John Surface

Mobile Application Developer

With a birth weight of just under seven and a half pounds, John has in less than three decades managed to gain thirteen stone and several years of experience as a full-stack and mobile engineer. He does his part to slow the spin of the earth spiraling out of control by creating robust backend solutions and intuitive cross-platform and native mobile applications.

Scaling a Push Notification Server

Scaling a Push Notification Server

John Surface

Previously we explored the topic of setting up a sandbox push notification server in Node.js. This featured a Mongodb instance to store users and device IDs, as well as endpoints to register users and send them the push notifications all at once. But what happens when you need to target individual devices instead of blasting your entire user base all at once? All of a sudden instead of processing one API call to send notifications to all of your users, you’re fielding multiple calls at once, possibly on the order of thousands of requests per second during peak user hours for your application. Fortunately, Node.js has built-in tools to help you scale your server.

The first issue we can tackle is breaking our Send endpoint out to work as a tool to send an individual push notification. We’ll assume in this case that the requests to this endpoint will come from another source with knowledge of the device Id and operating system to target. We’ll again use restify to set up our server:

 

//server.js

const restify = require('restify');

const server = restify.createServer({
name : 'pushTest'
});

// this allows us to parse the POST request body
server.use(restify.plugins.bodyParser());

server.listen(8080, () => {
console.log('listening on port 8080');
});

// set up a basic route
server.post('/', (req, res) => {
// parse the request body
let body = JSON.parse(req.body);

// check to make sure the body has the correct fields
if (body && body.platform) {
// send push here
}
// send a success response
res.send(200);
});

We’ll skip over actually sending the push since we covered that in our previous post. Once we start the server, we can use the ApacheBench command line tool to load test it. In a separate terminal window, paste:

ab -p test.json -c 20 -t 10 http://localhost:8080/

Where test.json is a local json file with test data. This will open up 20 connections per second for 10 seconds on our server. When we run this we get an output of about 150 successful requests per second, but let’s see if we can do better. The cluster module ships with node and allows us to spin up a server for every CPU we have on our machine. In a separate file we can have a “master” node that spins up servers for every CPU we have on our machine:

// master.js

const cluster = require('cluster');
const os = require('os');

// check if master
if (cluster.isMaster) {
// find out how many CPUs we have available
const cpuNum = os.cpus().length;

console.log(`Found ${cpuNum} CPUs`);

// fork the process for as many CPUs as we have
for (let i = 0; i < cpuNum; i++) {
cluster.fork();
}
} else {
// otherwise spin up server
require('./server');
}

Now instead of running

node server.js, run

node master.js

On my personal machine, this spins up eight different instances of the push server, and when I run our same ab command, I’m now seeing over 500 requests per second. This works by running master once and then running it again every time cluster.fork() is called for as many CPUs as we have. If master.js is entered as a result of calling fork, the isMaster call will fail and it will spin up the server.

This is a simple example of the built-in power of Node.js to increase the scalability of your application and expertly handle any kind of heavy load your test servers might need to endure.

John Surface

John Surface

Senior Developer

With a birth weight of just under seven and a half pounds, John has in less than three decades managed to gain thirteen stone and several years of experience as a full-stack and mobile engineer. He does his part to slow the spin of the earth spiraling out of control by creating robust backend solutions and intuitive cross-platform and native mobile applications.

Creating a Push Notification Server with Node.js

Creating a Push Notification Server with Node.js

John Surface

At Shockoe we’re used to integrating our clients’ complicated backend systems into our apps, and this often includes push notifications. However, to get that initial proof that our app is playing nicely with GCM and APNS we’ll sometimes rig up a sandbox server of our own. Since we’re used to JavaScript, Node is an obvious go-to. Here are the steps for rigging up a simple push notification server in Node.js. If you’re looking for a deeper dive into messaging 2018, you can also check out Shockoe’s Innovative Brand Messaging in a World Noise page shown below — it’s just as important to know when to use push notifications, especially in today’s saturated push-notification environment.

How to Message in a World of Noise

Push notifications without a sound messaging strategy can be quickly damaging to a brand’s reputation. See how Shockoe is working with leading companies to build the right messaging tactics to delight the modern-day user.

Learn to Message in 2018

A push notification server consists of two parts: storing deviceIds and sending push notifications. To achieve this we’ll create two endpoints: register and send. Register will utilize the mongodb node module mongoose and Send will leverage two platform-specific node modules: apns and node-gcm. We’ll also be using restify to set up our endpoints.

Register

For a basic implementation we only need two pieces of information: the deviceId and platform (Android or iOS). Technically–in some mongoose schema code golf scenario–we just need the deviceId, and could make both calls with one always failing.

So our mongoose schema, with the proper requirements, would look something like this:

const mongoose = require('mongoose');
const Schema = mongoose.Schema;

const Device = new Schema({
    deviceId : String,
    platform : String
});

const DeviceSchema = mongoose.model('Device', Device);

Mongoose is generally a lot more powerful than this implementation, with validations and enumerations that allow for easy error checking, but for the purposes of this demo we’ll use a basic schema. After making sure mongodb is installed and running on your machine, our restify endpoint would look something like this:

const restify = require('restify');

const db = mongoose.connection;

db.on('error', console.error.bind(console, 'connection error:'));

db.once('open', function(){
    console.log('db open');
});

mongoose.connect('mongodb://localhost/pushserver');

const server = restify.createServer({
    name : 'pushServer'
});

server.use(restify.plugins.bodyParser());

server.post('/register', (req, res, next) => {
    let body = JSON.parse(req.body);

    if (body) {
        let newDevice = new DeviceSchema(body);
        newDevice.save(err => {
            if (!err) {
                res.send(200);
            } else {
                res.send(500);
            }
        }
    }
}

Ideally we would perform a find on DeviceSchema to make sure we’re not adding duplicate devices.

Send

For Send we’ll implement a basic endpoint that will send a push notification to every device in the database. We can use a simple GET, grab the devices from mongo, and call functions to send the push, based on whether the target is an iOS or an Android device. The Android push module can take an array of deviceId’s instead of one at a time, so we’ll push those ids onto an array and call the sendAndroid function on all of them.

server.get('/send', (req, res) => {
    DeviceSchema.find( (err, devices) => {
        if (!err && devices) {
            let androidDevices = [];
            devices.forEach(device => {
                if (device.platform === 'ios') {
                    sendIos(device.deviceId);
                } else if (device.platform === 'android') {
                    androidDevices.push(device.deviceId);
                }
            });
            sendAndroid(androidDevices);
            res.send(200);
        } else {
            res.send(500);
        }
    });
});

Ideally we would only send the 200 response once we were sure that every push had been sent successfully, but for now it will indicate that the send functions were called.

Our sendIos function will leverage the apns module, which takes an options object. Make sure to include your push key and certificate .pem files at the root of your project:

const apns = require('apns');

const options = {
    keyFile  : 'key.pem',
    certFile : 'cert.pem',
    debug    : true,
    gateway  : 'gateway.sandbox.push.apple.com',
    errorCallback : function(num, err) {
        console.error(err);
    }
};

function sendIos(deviceId) {
    let connection = new apns.Connection(options);

    let notification = new apns.Notification();
    notification.device = new apns.Device(deviceId);
    notification.alert = 'Hello World !';

    connection.sendNotification(notification);
}

For android we’ll use node-gcm. Make sure you have your api key:

const gcm = require('node-gcm');

function sendAndroid(devices) {
    let message = new gcm.Message({
        notification : {
            title : 'Hello, World!'
        }
    });

    let sender = new gcm.sender('<YOUR_API_KEY_HERE>');

    sender.send(message, {
        registrationTokens : devices
    }, function(err, response) {
        if (err) {
            console.error(err);
        } else {
            console.log(response);
        }
    });
}

After that it’s just a simple matter of running your project and you’re ready to hit these endpoints and test push notifications on your app!

Want to chat about Push in your App?

We’re all ears! We’ll help your team communicate with your audience more effectively through app-based push notifications. Give us a ring and our team of strategist and developers will discuss with you ways to bring your team’s strategy up to tomorrow’s standards.

Node Summit 2016

Node Summit 2016

Last week I had the pleasure of attending Node Summit 2016 in San Francisco. I am eager to share some of the new cool technologies and concepts I learned about while I was there.

NodeSchool is a tool for learning node and javascript concepts. If you have node and npm installed, starting a lesson is as easy as installing a new node package; these lessons range from utilizing node tools, to the nuts and bolts of creating and publishing a node package.

The one hardware workshop at the conference proved to be perfect office hackathon fodder. Particle.io is a platform for interacting with internet of things devices, and using node and their Photon microcontroller we were able to program a row of lights to act as a scoreboard for a game of tic-tac-toe. As someone who deals strictly with software, it was a welcome diversion to play around with breadboards and resistors for a few hours.

One of the most insightful and fun presentations I attended during my time at Node Summit was on security. This talk featured a lot of great examples of trying to hack into or disrupt a locally hosted web application. Of course, the main thrust wasn’t to teach people how to hack–though I can’t say I didn’t learn a thing or two–but to show how out-of-date node modules can bring security vulnerabilities to your codebase. The presentation concluded with a stern warning that actual hacking was illegal and an insight into a current company for those in need of a fix:”bugcrowd” a platform that lets companies pay bounties to hackers to break into their systems so that they can close any security gaps.

The main buzzword at the conference was micro-services. Every sponsor from NASA to Netflix gave talks on how they have transformed their entire systems over to use this architecture concept.

Micro-services are not specific to node, but node’s flexibility means that it lends itself well to the concept. The micro-service pattern refers to breaking out all of the functionality of your product into independent pieces, instead of housing them within a single unit–known as a “monolith”. This way, when you make changes to your app, you don’t have to redeploy your entire codebase. Instead you’re deploying just the parts of the app that were affected by changes. This works especially well in node because you to pull in only the modules you need for each individual micro-service, and there are tons of node modules out there designed with communication between micro-services in mind.

Looking back at the conference as a whole, I was inundated with the vastness of node itself. Every year for the past four years the numbers of new node users has doubled, and there are 300+ new modules published every day. This has inspired me to try them all out and bring cool new technologies back to Shockoe.

Office Life at Shockoe: An Inside Look

Office Life at Shockoe: An Inside Look

John Surface

Shockoe is always facing new challenges, not least of which is where to put the millions of new people who have joined us in the office. Project managers to business analysts, to plain old software developers glue everything together. I’m not saying we’re packed in like sardines. Sardines are fish and they come in a can. We are humans and work in an office. And seemingly every day there’s a different subset of us here, as people jet set to meet with clients at the four corners of the Western hemisphere.

We’ve always had an open concept work environment, and with the new faces there’s always someone to talk with about work or football or the dangers of asbestos. However, the constant availability of tantalizing conversation has led to the phenomenon of people being “wired in”–putting on headphones to get in the zone. This is one of the best things that has happened at Shockoe because it means you can throw your old fruits and vegetables at people to get their attention. Another cool tool that we just started using, in case you don’t have extra tomatoes or are afraid of touching them, is Slack, a nifty instant messaging client. We’ve used email-based chat tools before, but Slack makes it easier to group messages by project, take opinion polls, or send videos, gifs, and emojis that describe one’s mood or place in the world throughout the day.

An easy analogue way to tell someone’s energy level, or at least mine, in the office is to see whether they’re sitting or standing at their desk. Ever since we got standing desks before the new year there’s a constant up and down in the workspace, as people alternately test their legs or give in to the soft embrace of a rolley-chair on the middle 50% of the back part of their bodies. I think if you were to film us for an entire day and then watch it sped up it would look like giant invisible hands methodically manipulating the keys of a large piano. It’s recommended that you stand for 80% of the day, which comes out to about 6 hours for us, meaning that if we follow this recommendation, we could stand for an extra two months out of the year that we would normally be sitting. That’s also 250 calories a day, or a bag of chips, which will hopefully be enough to fill the conference room by the end of the year, for diving purposes, a la Scrooge McDuck.

Snacks also make up an important part of our workspace, though usually we try to eat healthier than conference room chips. Stepping into our kitchen you will find a panoply of dried fruits and nuts (these start dry), along with life-sustaining peanut butter crackers (dry as well) and Greek yogurt (wet).

These factors—snacks, tantalizing conversation, activation of the glutes and core—combine to make a happy energy, which we harness to create what Shockoe is internationally renowned for: exceptional apps and spectacular blog posts.

Mock API Data and You: A Classic Love Story

Mock API Data and You: A Classic Love Story

A mobile app developer’s dream is to walk into the office on day one of the first sprint of a new project and find the bounty of a fully functioning web API laid before him. He locks eyes with the developer next to him and sheds a single tear, not out of sadness or even joy, but with the grim satisfaction that both recognize as meaning “We’ve earned this.” Before them stands a pillar of perfection, an endpoint standard that will never change throughout the lifetime of the project, a bastion of coding best practices that meets their exact needs. Sadly, this is usually not the case: API teams get delayed, endpoints get altered to an unrecognizable state, and servers go down for annoying, albeit necessary, maintenance. Thankfully there are several ways to simulate incoming data in the meantime.

Here at Shockoe we handle incoming application data in three stages: mock fixture data, mock API data, and client API data.

Mock fixture data is a simple tool: static properties that allow you to quickly lay out screens with plausible values. Pages load instantly, because you’re not making any API calls, which is useful in the early stages of constantly going back and forth between the code and the app to change a border width or a shade of blue.

Once the screens are laid out, however, it’s useful to make actual API calls that rely on Wi-Fi and mimic the latency of calls to the client’s servers. This can reveal cases in which the app should utilize blocking UI to make sure the user can’t click on anything else while the API call is going out, or instances where there should be an activity indicator if the wait is going to be long.

Here at Shockoe we like to use Mockaroo, a fantastic resource for mock data that can be accessed through their API. The steps are simple: create a schema for your data and populate it with the types of properties you want returned (eg Person, with firstName, lastName, address, phone). Then make a call to Mockaroo’s API, specifying the schema and return type in the parameters. These parameters range from city names and email addresses to formulas and regular expressions. The most important aspect of this data is the randomness. Programmers filling in fixture data might have never dreamed that they would see their city property populated with Parangaricutirimicuaro, but when Mockaroo sends it, it exposes the fact that the field is too short or overlaps with other labels.

Another useful Mockaroo feature is missing data. You can specify what percentage of the time you want a certain field to return a blank value, so you can be sure that your app handles this from both a UI and functionality perspective: making sure the interface still looks good when certain properties are missing, as well as not crashing.

The end goal is to make the process of integration to a client’s API as smooth as possible. Indeed, a project manager’s pillar of perfection would mean this process is a simple URL swap. And while this is almost never the case, the Shockoe process leaves us more than adequately prepared to face that crumbling pillar and get through with integration unscathed, no matter what comes our way.

Shockoe Wellness: Healthy Developers, Happy Developers

Shockoe Wellness: Healthy Developers, Happy Developers

There’s a reason the stereotypical image of a software developer is a slovenly mess, a large mass in a black t-shirt covered in potato chip crumbs, the reason being is it’s often true. And while we can’t prevent the ever-growing threat of black t-shirt wearing, we all do our best to keep those black t-shirts themselves from being ever-growing. Here at Shockoe we incorporate several exercises into our daily routine that we hope will improve our overall health. Collectively this is known as the Shockoe Wellness Program.

To keep our metabolisms engaged and the blood flowing through our brains, we’ll often take a stroll along the canal walk near the office. It’s also a great way to unplug from work for a little while and come back to any problems or tasks with a fresh mindset. Inside the office, ping pong is another great outlet to work through bugs and raise our heart rates. And for anyone who doubts the ability of ping pong to raise your heart rate, you’ve clearly never seen the crazy wall and ceiling shots we try every day and the mad dash of our developers to recover the balls as they go flying into the kitchen or under desks.

However, when you work in a profession that has you sitting and looking at a computer screen for eight hours a day, fitness is only one of your concerns. Here at Shockoe we incorporate several exercises throughout the day to help preserve our posture and eyesight. There are two main problems that face those who sit down for a living: forward head posture and anterior pelvic tilt. Speaking generally, from a blenderized knowledge of several internet tidbits, forward head posture comes as a result of, among other things, staring at a screen and inclining one’s head forward. Anterior pelvic tilt means that one’s hips have rotated forward, as a result of weakened hamstrings and abs and tightened lower back and quads due to sitting for long periods of time. To counteract forward head posture, we perform a series of neck exercises 2-3 times a day. Here is the video guide that we follow for these exercises. Vastly more information than I could ever provide about anterior pelvic tilt and the ways to counteract it can be found here, though the exercises that we tend to perform are the quad stretches and occasional stomach vacuums.

To help improve our eyesight, we utilize the 20-20-20 rule, which states that if you spend a lot of time looking at something directly in front of you (e.g. a computer screen), every 20 minutes you should look at something 20 feet away for 20 seconds. It also helps to roll your eyes and blink a lot during these breaks.

Shockoe Bods, a sub-branch of the Shockoe Wellness Program, is also very near to our hearts. It was through the Shockoe Bods program that we began a quest to each be able to do 100 pushups. For a while, every morning after our stand-up meeting we would crank out huge sets of pushups. However, we soon found that this was tightening our pecs and making us hunch over at our computers. We needed to add a complementary back exercise as well, so we hung a pullup bar near the bathrooms and encouraged people to do as many as they can every time nature called. For some, “as many as you can” was less than one, and that was perfectly ok. The prevailing wisdom is if you can’t do a pullup, simply hang on the bar for as long as you can, and the first pullup will come after being able to hang for 45 seconds.

All this may seem like a lot, but in total it may add up to ten minutes every day, which, in my opinion, is worth it to not be hunched over a walker by the time I’m 30. Every developer at the office is a huge fan of Bojack Horseman, and to paraphrase a touching moment from this past season: “It gets easier, but you have to do it every day. That’s the hard part.”

Interning at Shockoe as a Young Bachelor in the City

Interning at Shockoe as a Young Bachelor in the City

Many see an intern as the low man on the totem pole, and I am no exception. However, I bear this designation not with the corporate shame of an errand monkey, but with intense pride. I form the mighty foundation of our close-knit team of developers and managers here at Shockoe.

It is upon my broad, well-muscled shoulders that these lions and eagles of the mobile app industry stand to raise themselves to the highest of heights, achieving our clients’ wildest dreams and more. Above me on the totem pole, for example, is Bruce, a wise tortoise filled with an encyclopedic knowledge of javascript and enough puns to keep the entire office groaning all day. Or Andrew, the kindly giraffe, who picks leaves from the tree of debugging advice and fantasy football buzz, and brings them down to those who cannot reach. Every member of the team is helpful to me in different ways, and they amazingly all make time for me, never swatting away my questions like pesky flies…that would be a different type of debugging.

Now that I have regained control of my computer from Bruce I’m free to talk about all the different things I do here at Shockoe. In the two months I’ve been here I’ve helped design wireframes for clients, given my thoughts in mobile strategy meetings, tested in-progress apps, and currently, I’m even working on my own mobile app project, all while never getting coffee for anyone. Not once. They could have asked, and I probably would have done it, but no one ever did. It’s just never been that type of internship. True, there was some hazing at first, but after a few weeks, they finally let me hold the paddle with my hands during ping-pong brainstorming sessions.

One of the coolest parts of my day is walking into the office in the morning in full view of Main Street station, the most iconic building of the city I grew up in and love, whose clock tower confirms that I am in fact on time. Once I settle in and we have our daily stand-up meeting, I can get back to work on a bug I’ve been thinking about or a screen for an app that I’ve been designing in my head. Or I could be doing something completely different. If you’ll allow me, I’d like to augment my totem pole metaphor by saying that walking into Shockoe is walking into a jungle. There’s always a surprising new client or task lying in wait when I least expect it. I get a sense of adventure from working here, my steps cautious at first, but growing faster and more confident as I go along. And any sharp sensation I may feel on the back of my neck is not stinger filled with the deadly venom of a vicious predator, but the pleasant epiphany that I’m gaining more knowledge and experience every day. Either that or a ping-pong ball.