Sep
29

Working with Us

How does this whole thing work? Head to Hand. Brain to Phone. Lightbulb to Lightning Cable?

If you already have an idea of how building “apps” works then you’re most likely coming into the office with all your information ready and questions answered. However if you’re not really sure about how the idea gets from your head to the phone – we would like to give a little rundown of our process.

First. We discuss the idea.
There are two questions that need to be answered before any work can begin. First, what problem does this app solve? Secondly, who is the app for? If you don’t have solid and concise answers to these questions, you’re in for a whole lot of frustration and financial pain down the road. When you’re a month into development, and much too close to the project to remember where you started, you’ll love being able to go back and see if your new questions fit your initial value proposition. Yes? Great. No? Leave it. Knowing what you’re building prevents scope-bloat and allows for marketing/pitch success.

200-5

Second. We refine the idea.
Once we know what we’re building and for who, we sit down with our UX expert to refine features. You need a calendar app – great. Does the calendar need to send meeting invites? Do you need to see detailed listings or just high level? Do you want the views to be changeable (daily, weekly, monthly). Will the calendar send push notifications? What about having multiple calendars? As you can see requesting “a calendar” can have a lot of options.

We are here to show you what is ideal for your app and its users, what is possible, and what is cost efficient. When you say you want a house – is it this? or this?

screen-shot-2016-09-29-at-3-48-06-pm

During the ideation process we build wireframes. Wireframes are individual screen plans for all of the app’s features. The final wireframes allow us to give you a really strong idea of scope and timeline for development and serve as the app’s architectural plans. Without building wireframes we could guess at a feature list like “calendar, menus, list of cats” but it could easily fluctuate depending on what your interpretation of that feature really means (see the “houses” above).

Third. We design and test with real live users.
We take the wireframes and lay design on top. We will get a feel for the design on the project not only from who the targeted users are but also the brand and goals of the product. We do this in several ways – looking at competitors, apps the client likes, and making pinboards (yes, they’re useful for more things than your mom’s craft projects). We also place the design in a prototyping tool, Invision, where testers can click and explore. Post-design/pre-development is the best time to make sure what you’ve built works well with your users. You’d be surprised what you learn.

giphy

After the design is approved and flows are optimized based on user testing, the assets are exported and ready for development.

Fourth. We get to coding.
Our developers take the wireframes, designs, and interaction instructions and build “user stories”. These stories compose the scope of the project. “A user can tap a login button to view a login screen” or “A user can tap “support” to bring up a completed email” or “A user can view a loading animation”. These user stories are the meat of the project. If a feature is not clearly specified in a user story the developer will not know what to build. Or really – we can make assumptions. But we all know what happens when you assume….

Many times while coding, there are additional choices to be made (how should this baby be built under the hood?). With code being broken into smaller user stories a client can come in at any time and re-prioritize tasks, leave notes on current tasks, or adjust the plan without affecting the past work or current schedule.

Fifth. We test and deliver the code.
During development, when a set of user stories are finished (similar user stories are grouped into Epics – ie. “onboarding”, or “settings”) they are tested and reviewed by other crew members. If everything looks great, it is sent to the client. We generally like to send “builds” of code to the client at least every two weeks.

200

Steps Four and Five on repeat.
Code. Review. Test. Code. Adjust. Review. Test. Adjust. Code. Code. Code. Review. Test.

Sixth. We publish the app.
When everything is ready for a current version – we push it to the app store. That doesn’t mean it magically appears in a user’s hands. Apple and Android once again review your code and make sure it is in working order for the user. After their approval, it is in the store ready to be downloaded, promoted, and used by your adoring fans.

200

Jul
26

Shipping Your First App

[message_box type=”info”] This week we have a guest post from LunarLincoln Intern Dheeraj Namburu. He spent last month working on his very first app project and we wanted him to give us a breakdown of his initial foray into development and his take on our product-process. Enjoy! [/message_box]

Coming up with a good app idea is hard: it needs to be unique, useful, and attractive enough to attract a paid user. Hitting all of these criteria is essential in developing a successful app as I’ve learned these past few weeks. My first app ”The IFJ Reader” was a tool to make reading Intercollegiate Finance Journal articles much easier on an iPhone. The important distinction with my app is that I wasn’t seeking a profit, I wanted it to be a learning guide so that I could move on to other projects.

The best way to start the ideation process is to come up with as many ideas as possible – brainstorm. Your first few ideas may suck but you’ll find one to stick with. Choose something you’d actually want to use and find a way to make it unique, useful, and profitable. I decided to make an app that would help other people in my organization read the work that they’ve published. It’s important to be passionate about the idea you have while having some support from the user base. Your focus won’t dwindle when you get frustrated with all the minor issues that pop up because you will be accountable to the people for whom you’re making the app. You will fatigue, so you might as well choose something that you would appreciate spending day and night on (not that you will but still).

 

Planning Is So Important

The less you change your app design throughout your development process the fewer headaches you’ll suffer. Getting to create your own app gives you the ultimate control over the end product. I initially overreached on my first app and tried to add features like favoriting and searching that took too long to implement. Learning to trim the fat for your first MVP (Minimum Viable Product) will be invaluable while you’re designing your app.

It’s also important to understand the need that your app fills. If a feature doesn’t promote the solution that your app promises, that feature may need to be revised or scrapped entirely. It’s important to keep the scope of your app narrow, so that your focus is driven towards things that will reap the biggest benefit for a user.

Also, it’s important to do market research; it’s more than likely that someone has created something similar and you should take that into consideration. I looked at other RSS feed reader apps and determined what features they’ve implemented and what I could do better than them. Is the market saturated? If so, is your app specific enough that the people in your niche would use your app over others? Act like a user: Is your app flashy enough to capture the two-second attention span of an average human being? Is it compelling enough to compete with similar apps? While these criteria are important when trying to make a commercial success, it may be worthwhile to fulfill these criteria even on a side project. I made sure to develop an app that fit a small enough niche, that even in the RSS feed-reading category, my app would appeal to readers of the IFJ.

 

Make Rough Estimates 

Determining how long it takes for one to finish a task is an invaluable skill that takes time and practice to develop. Making estimates is a key tool to help finish projects on time. Appropriate estimates can help determine what the timeline is and if certain features can be added or cut based on the time frame remaining.

I wouldn’t worry if your time estimates were wrong, my first estimates were all over the place. Wiley helped narrow my focus and develop a more realistic timeline and this helped me take an app that I thought I could develop in a week, to a more manageable 3 week timeframe. The entire estimation and user story process allowed me to break a big task into smaller ones and allowed me to appropriately allocate my time to different tasks.

Screen Shot 2016-07-29 at 10.05.20 AM

Not only do rough estimates help you plan, they also feel rewarding whenever you finish a story. These small successes help you realize your goal and help fatigue from setting in, but they may also cause some tunnel vision. It’s important to avoid focusing so much on the small tasks and neglecting the bigger picture. It’s hard to see the end when it’s nowhere in sight, but it’s a good habit to step back once in awhile, admire what you’ve accomplished and get right back to work.

 

func  startDeveloping () {

Congrats! You’ve come up with an idea that you like, you’ve conducted market research to refine the idea, and you’ve created some rough estimates for each feature you want to implement. Now comes the actual coding part. Depending on your app, it’s important not to reinvent the wheel; just do a cursory search on Google to find libraries or examples of apps that attempt something similar. This way, you’ll save time and effort by piggybacking off of someone else’s work. Keep in mind, if you run into errors, debugging someone else’s huge code base written five years ago won’t be easy. Taking into account the benefits and drawbacks of outside codebases, it’s important to use them wisely, while writing custom code for any critical functions.

Coming in as a first time iOS app developer, I was kind of frustrated with the fast pace of mobile development. I learned to write in Swift but a lot of answers online were in Objective-C and translating between the two was difficult. I used a lot of help from the veteran developers here (everyone but me) so I had a competitive advantage. However, StackOverflow and Stanford’s online app development course were invaluable debugging tools. I’m glad I live in the age of the internet because I would’ve asked a lot of stupid questions in the office without it!

}

 

upload

QA and Review – Make Sure Your App Works

QA was minimal for my project, I mostly utilized my own testing of the app installed onto my phone to test the features that I wanted to and to ensure that the app would layout UI elements properly. I would fix whatever I could and then ask the developers here how to fix the other issues. Jennifer gave me valuable UI critiques, while Wiley, Patrick, Travis and Jack helped me write reusable and robust code.

While testing in-house is appropriate when creating a final product, it’s important to test the app in the field with actual users. To refine my idea, I decided to add some of the members from the IFJ to “TestFlight” the app. Having external testers requires a beta app review, but it also allows for easy app testing from end users, and this step can bring in valuable information for later revisions. Analytics and testimony from the users can help pinpoint trouble spots in one’s app and allows a developer to apply a polish that appeals to the end user.

Once all QA is completed, it’s a good time to send the app to review by Apple via iTunes connect. Get your killer app icons, screenshots and description text ready as you head to the App Store while you gear up to submit!

 

Post That App

The best part of doing all of this work is submitting to the App Store! Congrats, you’ve gone through the process of completing the development cycle of an iPhone app. Assuming your app has passed Apple’s review process, you can now post in the App Store. Pop out the champagne and celebrate!

Oh, but wait, no one’s gonna download your app if you don’t promote it… get out that old Twitter/Instagram account and start posting! Reach out to other people you know to get them to tweet about the app, do everything you can to get your app’s name out there. Leverage social media accounts, email lists, paid and free ads, anything that will get your app to the top of the App Store list.

 

Bathe in the Digital Benjamins

In the end you’ll have shipped your first app to the App Store. A process that might feel long and difficult, but relatively painless when compared to traditional application shipping. Thank your Apple overlords as you rake in that sweet app money.

Apr
06

Native vs Web Apps

When building a software product for mobile, there comes a time early on when you must decide between building a native application or a responsive web app. When making such a decision, it’s very important to understand the implications of going one way or the other. A native app is typically more expensive to build, but the extended capabilities and high speed execution often makes it necessary or at least advantageous for certain products. Today we’ll explore a few benefits of building native apps to help make this decision easier for anyone setting out to build a new mobile product.

blog-42

Why go native?

Direct Hardware Access

Icons8One huge advantages of natively built applications is they have direct access to many hardware features that web apps simply do not. While HTML5 has brought easy access to the camera and microphone with the <input> tag, these elements simply output a file and don’t give you access to the media in real-time. If you want to build fun camera filters or do any kind of signal processing, you’re much better off in the native realm.

While web apps have some access to media capturing hardware, they don’t have any access to some of the other sensors on the device. For example, native apps on iOS have full access to all HealthKit data (should you allow them) collected by the motion co-processor and other activity trackers, which are always working whether your app is running or not. Native apps can also use geofences and other location-based triggers to provide context-aware behavior and offline notifications, which can draw your user’s attention back to your app at opportunistic moments.

Blazing Fast Execution

200 (4)Native apps can work more efficiently because they run directly on the hardware, meaning there’s very little overhead to performing computation. This can make a huge difference when doing lots of graphical work or anything that is computationally expensive. While hardware-targeting makes applications less portable, it allows them to really take advantage of the processors they run on, giving you the high resolution and fluid graphics you see in native games and media apps today. Apple’s graphics library Metal is a great example of this, being designed specifically for the GPUs in Apple’s products to achieve maximum performance.

User Experience

There’s usually a clear difference in appearance and quality between native and web-based apps, as web apps lack the responsiveness and familiar UI elements of a native app. While web apps can certainly accomplish a lot, the extra layer of separation brought by running in a browser or web view rather than natively means the app can’t respond as quickly to things like touch events. This accounts for the slight lag you experience when interacting with the UI of web-based mobile apps, which amounts to a less-than-stellar user experience. Also, users may not pick up on custom UI controls from the web when they are used to a consistent experience from native apps on their platform, which can lead to usability problems. If the user feels like they’re swimming upstream to use your app, they probably won’t keep at it for long.

Offline Functionality200 (1)

One clear limitation of web apps is the necessity to download them over the internet each time they are loaded. Since native apps are installed once and can store tons information on the device, they can provide all kinds of functionality without an internet connection. iOS apps can even preemptively load data before the user opens the app through silent push notifications that “wake up” the app to retrieve new data.

Even with an internet connection, the first few seconds of a web app experience often consist of spinners and sluggish stylesheets causing elements on the page to jump around as it loads. This requires a measure of patience from your user, which might be too much to ask from some users especially after navigating through a few pages. With user attention spans getting shorter and shorter, you need to capitalize on every second they spend in your app, creating value for them and not putting them on hold to download and render bloated web pages.

In short, while native certainly isn’t the right choice for everyone, there are a quite a few cases where it’s necessary or at least beneficial. It’s important to consider these implications not only for the current state of your product but also for it’s future, as it would be unfortunate to commit to a web-based platform only to have to rebuild later when you need native-only features. While historically writing native apps have meant coding for one platform at a time, there have been big developments in native, cross-platform solutions such as Xamarin, now backed by Microsoft, and React Native, brought to you by Facebook. These solutions, while still growing, hope to deliver the fully native experience without limiting you to a single platform which can greatly reduce the cost of certain projects.

Mar
30

Mobile Madness – Final Four

The results are in and the winners from yesterday are: Swift, AWS, Jake Wharton, and Steve Ballmer. Here is your updated Bracket.

I can’t believe we’re already at the final four.200

What is the essence of mobile development? Will it be a person? A service? A language? How did we get here and what happened to all those past contenders?

[separator type=”” size=”” icon=””]

Amazon Web Services vs Swift

Amazon Web Services has proven it’s worth in Mobile Madness as the powerhouse of cloud computing. The depth and breadth of it’s services speaks to the totality of it’s domination. AWS prides itself on it’s high scalability potential, which they’ve made clear by naming everything elastic. Swift, however, is no force to be trifled with. With 2.2 hot off the press, the language is still rapidly improving and shows no signs of slowing down. It’s also been proven with science that Swift developers are the beardiest. Show your support in today’s Twitter poll!


aws_logo

icon

[separator type=”” size=”” icon=””]

Steve Ballmer vs Jake Wharton

Which tech-celebrity will come out on top? Will it be Steve Ballmer, with his unending passion for Microsoft and smooth dance moves? Or Jake Wharton, who continues to amaze with his Java mastery and penchant for making awesome libraries that you’re probably already using. Who will make it to the final round? Cast your vote in today’s Twitter poll! Answer the twitter poll here


ballmercrazed

imgres

[separator type=”” size=”” icon=””]

*** We somewhat cheat and pre-write these posts an hour or two before the closing of the polls each day but today we faced a huge upset. As of 11am Felix Krause was winning and so we wrote an awesome post where we discovered that Felix is a soccer-robot world-champion builder. UNFORTUNATELY, Steve Ballmer, with his wily ways pulled ahead at the last minute. (Amazing. Could it have been super delegates?) And so we had to edit our post, but felt that if we had shared with the world this fun-factoid earlier, perhaps results would have been different.

Mar
29

Mobile Madness – Elite Eight

The results are in and the winners from yesterday are: iOS, Swift, Erica Sadun, and Jake Wharton. Here is your updated Bracket. We’re moving on to some strange pairings. We’re getting into the really abstract comparisons of what is “the best” here at Mobile Madness. Join us on this journey.

[separator type=”” size=”” icon=””]

Steve Ballmer vs Felix Krause

This is getting hard guys. The insane cult-of-personality that is Steve Ballmer or the straight up utility and approachability that is Felix Krause. Don’t make me make this choice!
Answer the twitter poll here


ballmercrazed

photo

[separator type=”” size=”” icon=””]

Erica Sadun vs Jake Wharton

Ultimate indie expert battle – still iOS versus Android in this bracket. In one corner – Jake Wharton and his 1 billion excellent open source libraries and in the other corner Erica Sadun – Queen of Swift. Make your pick. If you can. Answer the twitter poll here


sadun_erica_c

imgres


[separator type=”” size=”” icon=””]

Xcode vs AWS

Ok, whew, this bracket got weird. Let’s compare a development platform with a cloud service. Both are massive industry standards but which works better? Which is more integral to development?  Answer the twitter poll here


icon128-2x

aws_logo

[separator type=”” size=”” icon=””]

iOS vs Swift

The parent or the child? What do you think of iOS as a platform in general? Is Swift its best incarnation? Is the future of iOS brighter with Swift? Can iOS win all bets as an innovator in its own field? I don’t knowwww! Answer the twitter poll here


poster_large

icon

Mar
24

Mobile Madness – The Tools

The results are in and the winners from yesterday are: iOS, React Native, Objective C, and Swift (Obviously some apple fan-boys out there). Here is your updated Bracket.

[separator type=”” size=”” icon=””]

On to the final first-round bracket of Mobile Madness 2016. The Tools. You need them, the love them, you hate them, you shout whyyyyy at the sky while Xcode hangs. Which is the best? Which is crucial to mobile development? Let’s begin.

First up: iOS Tools

Xcode vs AppCode

Xcode gets a lot of flack from developers because Apple more-or-less forces their developers to use it. Sure, it has tons of great features and debugging tools, but every little glitch or crash becomes colossally irritating because of a lack of alternative options. Enter AppCode, JetBrains’ introduction into an iOS and OS X IDE. AppCode attempts to solve a lot of the headaches Xcode creates, like improved refactoring support and auto-generated snippets. But AppCode comes with a hefty price tag and often lags behind when Apple releases new APIs. Is the increased convenience worth the cost? You decide! Answer the twitter poll here


icon128-2x

OBJC

 

[separator type=”” size=”” icon=””]

Second Bracket: Android Tools 

Android Studio vs Eclipse

Eclipse has long been a Java programmer’s goto IDE for all of their needs. Console applications, GUI applications, applets, web apps, and more can all be cranked out from Eclipse. It’s no wonder why Google initially supported Eclipse when they debuted their Android SDK. But now a newcomer on the scene, Android Studio, has stolen the spotlight and captured the hearts of Android developers everywhere. With Google officially deprecating their Eclipse support and actively promoting Android Studio, you might say the sun is setting on Eclipse for Android development. But that hasn’t deterred many Android developers who have been using Eclipse for years and don’t feel the need to switch. Which will reign supreme: comfort or cutting edge? Answer the twitter poll here


Android_Studio_icon.svg

eclipse-1

[separator type=”” size=”” icon=””]

Third Bracket: Continuous Build Systems

Jenkins vs Travis CI

When it comes to making sure your code is stable, Jenkins offers a great set of tools for building, testing, and more. As an open source project, Jenkins provides a high level of flexibility for implementing real continuous integration for any platform. Additionally, it’s free (as in beer)! Travis CI, much like Jenkins is no slouch when it comes to building your apps. With a beautiful interface, you can quickly check that status of your project. Additionally, Travis CI manages the infrastructure for you making it one less thing to worry about when it comes to working with CI tools. Which mustachio’d tool do you prefer? Answer the twitter poll here


headshot

687474703a2f2f61626f75742e7472617669732d63692e6f72672f696d616765732f7472617669732d6d6173636f742d32303070782e706e67

 

[separator type=”” size=”” icon=””]

Fourth Bracket: Cloud Storage

Heroku vs AWS

From the juggernaut that revolutionized online shopping, Amazon is using their knowledge to provide the best in cloud computing. With it’s massive offering of paid services, you can design, build, and deploy all your digital content in a matter of minutes. If you have a DevOps need, Amazon has a service for it. On the other side is Heroku, the developer friendly infrastructure service. Heroku can help developers by clearing out the chaos that can come with managing your own stack, like with tools to automatically deploy and push on each code commit. As your application needs to scale, Heroku’s marketplace of paid add-ons is sure to have what you’re looking for. Answer the twitter poll here


heroku

aws_logo

Mar
23

Mobile Madness – The Code

The results are in and the winners from yesterday are: Limor Fried, Erica Sadun, Jake Marsh, and Jake Wharton. Here is your updated Bracket.

[separator type=”” size=”” icon=””]

On to the third bracket of Mobile Madness 2016 with the numbers, the code, the languages and platforms. FULL STACK BABY!

First up: The Kings of the Mobile Kingdom

iOS vs Android

iOS and Android have been battling it out in the mobile space from day one. Globally, Android has a whopping 84.7% marketshare while iOS has only 13.1% (Q3 2015). Having multiple hardware manufacturers and OS distributions, Android provides many options to the end user, but at the cost of a consistent and reliable experience between them. iOS can deliver a high quality experience across all devices because Apple is fully in control of the design and production of their hardware and software, but it comes with a higher price point and fewer options.

AndroidvsiOS

So which wins? Beauty or Breadth of Market? Answer the twitter poll here

[separator type=”” size=”” icon=””]

Second Bracket: Everything to Everyone: Cross Platform 

React Native vs Xamarin

React Native is a version of Facebook’s React.js, developers can write javascript that controls native UI elements among other things. React has been praised for it’s architectural design and the resulting increase in developer productivity. Xamarin, recently acquired by Microsoft, is a cross-platform development solution for writing native apps in C#. It comes with a robust IDE called Xamarin Studio that makes building cross-platform apps a breeze. One major difference between the two is that React Native is open source, while Xamarin is not only closed source, but requires a monthly subscription to use (but you get real support!).


react-logo-1000-transparent

RDXWoY7W_400x400

 

Who knew we’d bit pitting Facebook against Microsoft in a mobile development battle. What do you think of these unlikely platform contenders?  Answer the twitter poll here

[separator type=”” size=”” icon=””]

Third Bracket: Languages in the Key of C

Objective C vs C++

While both languages are in the C family, Objective-C and C++ have some huge differences. Objective-C is a dynamic language where everything compiles down to C code that uses the Objective-C runtime library. C++ is usually compiled to assembly and has no runtime library which means it’s generally much faster. Most Objective-C programs are now compiled with ARC which will manage memory for you, whereas a C++ developer must be very careful of how they allocate and free memory in their program. Objective-C has proven very productive for writing high-level code such as UI or business logic. C++ is less productive but much more powerful when you need to work at a low level, like when implementing high-performance graphics or audio processing.


url

CPlusPlus

High brow or low power? Which C will it be? Answer the twitter poll here

[separator type=”” size=”” icon=””]

Fourth Bracket: Old Kids and New Kids

Java vs Swift

Java is generally accepted as the most widely used programming language today, and has been for some time. Swift is quite new on the scene, which only hit 1.0 in September, 2014. Swift has been acclaimed for it’s use of functional programming and value types which can help simplify problems in the minds of developers. Java works mostly with objects and reference types and only recently added functional programming capabilities through lambdas. Swift is entirely open source whereas only some Java implementation are (see OpenJDK). Swift still has much to prove for general use outside of iOS and Mac apps, but support from the open source community as well as big players like IBM is driving adoption for the language at a rapid pace.


Java7VM

icon

Answer the twitter poll here

Mar
09

Helping clients out with the tech terms

Everybody knows that software development depends on understanding various programming languages like Java, Swift, and Objective-C. But sometimes the most difficult language to understand is our own.

jackie-chan-illuminati

Tech geeks and project managers often have an unfortunate habit of using vocabulary that is lost on the ears of their clients. We use certain terms and phrases all the time and forget that we work in a niche environment. I want to take a moment and demystify some of the lingo we use when talking about our work.

Server

A server can be thought of as a computer program which runs code specifically for Internet applications.  For example, websites are hosted on servers.  A server isn’t necessarily an entire computer (sometimes a single physical computer can host many servers) but for the sake of understanding, imagining a server as a single physical device works just fine.

Back-end

More often than not, mobile applications need to connect to the Internet to perform their feature sets.  The back-end is what we call the server that powers our applications.  If we have to store user accounts, fetch data for various screens, or any other feature that requires external data, we’ll talk to a back-end.  Some services like Amazon Web Services and Parse offer simple back-end solutions.

Front-end

As opposed to the back-end which is strictly computational, the front-end is what the users get to see.  A front-end can be a website, a mobile app, or any other visual interface for your product.

When building a website you often need a “front-end” developer and a “back-end” developer since each part’s code works in fairly different ways.

API – Application Programmable Interface

An API is the means by which a back-end serves data to external applications – a set of instructions for a specific task if you will.  For example, if I created a back-end for storing user accounts, I would create an API endpoint allowing my app to save a new account (sending new accounts to the server back-end).  Each endpoint on an API performs a specific function (or set of functions based on the query parameters given to it).

Untitled

APIs link different things up with translatable instructions.

Push

Push can mean many things, but for brevity sake, I’ll only talk about the two most common times when we use the word ‘push’.  Every product we make is backed by a version control system called git.  A full explanation of git would take at least one or two more blog posts, so I’ll spare you the details on how it works.  When a developer has finished a task an wants to save his or her code to the central repository, they ‘push’ their code up for review.  Similarly, the other instance we use the word ‘push’ is when submitting finished products to their respective app stores.  Both instances of the word ‘push’ have to do with submitting finished work.

If you don't push your code - it won't be added to the main codebase

If you don’t push your code – it won’t be added to the main codebase

Build

In our world, the word ‘build’ is used often as a noun.  A build is a compiled instance of an application.  For example, if I wanted to send a beta version of an application to a client, I would create a build and push it out for testing.  One might say that they’re ‘building a build’ which would mean they’re preparing to distribute a version of the application.

release

Source Code

Not to be confused with the terrible 2011 Jake Gyllenhaal movie, source code is the main body of code that composes your mobile app or website. We often break off small chunks of code to work on (branches), but when we’ve properly added to this piece and tested it, we then push it back into the source code. When we are done with a project, we will send you the “source code” aka all of the code that is needed to run or “build”  the project. Often if we are working with a new client who already has a product, we will ask for access to their “source code” to see what has already been written and the quality of code that we will be working with. Is it going to need some restructuring? Is it all tidy in there? How is your app built?

User Story

A user story is an example of a feature we’d like our application to perform from the perspective of a user.  For example, if we have a screen that allows users to sign up, a user story might say, “A user can enter their credentials to sign up for an account”.  This ideology helps us imagine our goals as if we were using the application instead of building it.

user-story-card

Agile

This is how we operate!  Agile development focuses on building features incrementally and with room for flexibility throughout the project.  Whereas more stringent methodologies such as Waterfall rely heavily on extensive planning, Agile is a more rapid system.

agile-methodolody_695x260

Iterate

When we say we’re going to iterate on an idea, what we mean is we will keep making tiny changes, builds, or designs until we slowly, gradually develop what we are building into the ideal format. Instead of building once and declaring “This is it!”. We will frequently iterate over tough problems until we arrive at the best workable solution. Iteration is the core of the agile methodology (see image above).

That’s it for now you guys. Hopefully this has been an informative tech terms 101 for you. Now you can sit in meetings and nod wisely as we blather on about “taking the most recent iteration and pushing the back-end source code build up to the server“. Let us know if there is anything else we missed or if we need an entire round 2 of “What the heck are you saying?”.

200-2

 

Feb
04

From office noob to Android czar – Building a League of Legends App

[message_box type=”info”] This week we have a guest post from LunarLincoln developer Travis Smith. He spent 2015 working on a side project which he finally shipped (yay, shipping!) and we wanted him to give us a breakdown of his initial foray into indie development. Enjoy! [/message_box]

Sometimes it’s hard being the only Android user in a shop full of mobile developers.  You’d expect nearly equal representation as Android currently dominates global markets, but alas, mistakes do happen (yes, mistakes). However, a positive consequence of this misfortune is the compelling urge to prove Android is the superior operating system. And what better a way to do that than to become an expert Android developer.

chart-ww-smartphone-os-market-share

Android’s Lollipop OS was released around the start of my development journey and alongside it the beautiful style guide known as Material Design. Coupled with the release of numerous support and design library features, I knew I wanted to create something awesome both as practice and for fun.

giphy-2In addition to being the only Android user in the office, I’m also the biggest video game nerd. My favorite these days is League of Legends, arguably the most popular PC video game in the world. And luckily for me, Riot Games, released a beta version of their public API just a few years ago. Being no stranger to the Riot API (I rigged up an automated system to pull in millions of game records for statical purposes back in early 2014), I knew I wanted to push both my skills and the API to their limits. But where to start? There were already a handful of League of Legends apps in the Play Store and some had hundreds of thousands of downloads.

What was a problem in League of Legends that hadn’t yet been solved?

Friends. All of the existing apps I found made it easy to drown yourself in data and statistics about any player you wanted. However, none of them made it easy to see how your friends were doing, or whether they’re actively playing a game at the moment you’re using the app. Additionally, all of the existing apps were designed before the advent of Material Design.

I could see in my mind what I wanted:

  • A name. I chose League Buddy. It’s simple, a little corny, not violating any copyrights, and unused. Works for me.
  • The home screen should be a list, or maybe cards, of summoners.  I could show their names, their profile pictures, and when they last played a game (or if they were in game that moment!)
  • A Floating Action Button at the bottom could present a popup of some sort that allows users to add new summoners to their list
  • A single swipe to refresh could update the entire list at once and let me know immediately if my buddies were playing without me
  • Tapping a summoner should do… well, something. I hadn’t figured out exactly what I wanted here yet. Maybe show some in-depth detail about the summoner?

Simple, right?

Time to learn some new tricks.

Around the time I started, Android released its ‘upgrade’ to ListView, the RecyclerView, and encouraged developers to stop using the ActionBar and instead use the new more generic Toolbar, which would prove very useful in implementing a core Material Design feature. I had my first screen laid out in my mind, but I still had a few questions.

  • What are the best practices with Activities and Fragments?
  • Does the Toolbar belong to the Activity or the Fragment?
  • What about the Floating Action Button?
  • What if I want to support multi-pane on landscape tablets? How should landscape look in general?

I spent so much time researching everything about best practices that I actually discouraged myself for a few weeks. Eventually I realized that the only way I was going to really learn what worked and what didn’t was by trying my best and fixing my mistakes.

giphy

Since I knew I only had one screen in mind, I decided to put multi-pane support on the back burner. However, I did prepare for the future and opted to implement my layout inside a Fragment (which was really just containing a RecyclerView) and put that Fragment in my Activity along with the Toolbar and Floating Action Button. Back then, I was using a library for the Floating Action Button since there wasn’t an official widget (yet). I created a small view that would slide up from the bottom when the button was pressed and that view allowed users to input a summoner’s name along with the region of the server they played on. For example, I play on the NA (North America) server, but there are about a dozen servers across the globe and I wanted my app to support them all.

unnamedNow I needed some way to persist data. On a previous project at work I had used Sugar ORM as a wrapper on a SQLite database. It worked well but I wanted to try something new. I came across a brand new tool called Realm which touted itself as being incredibly fast. Though still in beta and lacking some features (including null support and subclassing entities), I decided to give it a go.
All that was left was to set up the actual connection to Riot’s servers. Writing an API wrapper was easy, especially since most of my code from my previous Riot API project was up-to-date. I used Retrofit to talk to Riot’s server and Picasso to display profile pictures. After a few nights of work, I had accomplished my goal – an app that showed a list of summoners, with a button to add new people, and the ability to refresh the list. It was crude, not too pretty, and lacked lots of key features (like deleting summoners from the list), but it worked.

And then I stopped working on the project for a few months. Work picked up and summer meant vacations, so I halted progress.

But then, Android released some neat new tools that inspired me to resume development!

The first was an official Floating Action Button. The second was a new view called the CoordinatorLayout which allowed the Toolbar to hide as the list below it scrolled down. Last was a NavigationView class which made implementing a Material-themed navigation drawer incredibly simple.

Implementing the CoordinatorLayout proved to be very challenging. I had placed a view at the bottom of my fragment that indicated the last time the data had been refreshed, and this was throwing off the scrolling of the fragment. Despite aligning the view at the bottom and the RecyclingView above it, the scrolling did not work properly. Somebody else had filed a bug report about this exact issue and fortunately somebody had devised a workaround. However, now that the Toolbar slid out of view when scrolling my summoners list, I couldn’t imagine how multi-pane support would work at this point. My second screen was scheduled to be a scrolling list of cards containing tidbits of high-level information about a summoner, and having two scrolling views under one Toolbar would be very unwieldy for a user if that Toolbar was also sliding.

The next hurdle was the Floating Action Button. Now that Android had an official widget which directly related to the CoordinatorLayout (the button would hide on scrolling), I knew I had to replace it. However, I disliked my current implementation of adding a new summoner. A messaging app called GroupMe provided some much needed inspiration. When tapping their Floating Action Button, the button expanded outward until it filled a small rectangle. I loved it and had to have it. As it turns out, this animation is called a circular reveal animation (surprise!). Android had incorporated a utility class for performing this exact animation, but it was limited to devices running Lollipop or newer (which was a very paltry 10% around this time). Fortunately I found a library that provided the exact needed functionality to my app.

unnamed-1Along the way I encountered a new pattern I had never seen before: the event bus. While I’m still torn today over its fit as a best practice, I decided to integrate Otto into my app to help with loading and passing data. In hindsight, I regret this decision a bit, as it led to some poor coding practices and tangled dependencies. As practice, I also decided to upgrade all of my API calls to return RxJava Observables, as functional reactive programming is something I’m becoming more and more interested in.

Creating the summoner overview cards screen was fairly easy. The card styles were adapted from official examples and look very clean. I was able to use a StaggeredGridLayoutManager to allow different orientations and screen sizes to show different numbers of cards side-by-side. Because of switching to using RxJava Observables, loading all of the necessary data (since none of this data is persisted) was easy. I threw together a quick Settings screen which let users change their default region (which will be automatically selected when prompted to add a new summoner) as well as their preferred language (which all Riot data will be automatically translated to).

After a brief QA round across different devices and SDK versions, I had a working, ready app. With one problem.

Riot’s development API key is severely rate limited. To get a production level key, I’d need to get them to approve my app. And to do that, I had to follow their rules. The first rule is that no client-facing application can have the API key embedded in its code. This meant I needed a server to act as a middleman between my app and the Riot servers to append my API key and return the data. The second hurdle was that I needed a website to showcase my app and provide screenshots, FAQ, etc. I took my meager bit of Node.js and Express knowledge and pieced together a very small server application which would cache results for a few minutes and return the data to my app. I hosted this on DigitalOcean, struggled to get a free SSL certificate, and eventually got it working. I purchased the domain leaguebuddyapp.com and worked with Jennifer to set up a very simple one-page website (which is almost done, I swear!).

200

(^Jennifers reaction to this statement)

I was ready to publish.

Presenting, League Buddy! It’s small, it’s nowhere near finished, it’s got some kinks, but it’s mine. I’ve got tons of ideas for future expansions to the app. A wiki page with data on every champion and item in the game, a statistics section that lets you compare yourself to your friends (or even professional LoL players, if you dare!), and tons more cards on the summoner overview screen. Not to mention all the detailed pages for nearly every card! I’m going to be busy for a very long time.

leageulegends

 

Despite the incredibly long blog post, this doesn’t cover even half of the sometimes silly and often frustrating problems I encountered on this journey. But I feel it was completely worth it.

I’ve exposed myself to so many new communities, picked up so many new skills, successfully learned which patterns I like and which I don’t, and ultimately shown I’m capable of creating an entire application from scratch, including its server and web components. It was fun, challenging, and awesome. With 2016 under way and my routine back to normal, I’m hoping I can commit a little bit of time each week to cranking out some new features.

In the meantime, check out my app and let me know what you think! I’m open to all criticism and suggestions for improvement.

And I should offer thanks to the entire LunarLincoln team for putting up with my rambles and questions over the last year about this hobby project. Even though they’re not exactly Android fanboys and girls, they’re all brilliant and offered tons of great suggestions. I’m immensely thankful for their help and looking forward to using my new skills on upcoming Android projects.

Oct
28

VandyHacks

Zack Morris Cell PhoneWe’ll let you in on a little secret – smart phones didn’t even exist when we were in college (other than early Blackberrys). LAN Parties were super high-tech and the App Store wasn’t open to developers until July of 2008. As a result, events and hackathons like VandyHacks weren’t an option for undergrad Jenn & Wiley.

A lot has changed. For the tech world in general and for the learning opportunities available to new developers. We decided to help sponsor this year’s VandyHacks as a way to give back to younger versions of ourselves and dive head first into the whole mentoring thing.

During the event we were available to provide advice, guidance, and a lift over the hard parts of assembling an app from scratch. Shout out to Travis and Ben for pulling several all nighters with student teams.

vandyhacks

On top of that, we also gave a talk about building apps at a higher level – looking beyond the mere code.

We compiled the talk as well as lots of handy resources as a page on our site that can be found here. But, its not just handy for the VandyHackers, ANYONE can use this stuff.

Amazing goodies available at that link:
  • iOS & Android Tutorials
  • iOS & Android Favorite Tools/Sites
  • Wireframing Printables
  • Resources for GUI design kits
  • Prototyping Programs
  • Photoshop & Sketch Tutorials
  • The secrets to life – vis a vis a LunarLincoln slidedeck

 

The weekend was great. We met some fantastic future developers, and gave out a prize to a team from Georgia Tech that built a pretty great simulation game with Google Tango as freshmen – Catching Cubes! (Talk about ambitious). Congrats to: Miti Joshi, Tessa Jensen, Zac Romick, and Vritant Bhardwaj.

shootformoonwinners

Copyright LunarLincoln 2025. All Rights Reserved