Many of you already know the buzz going on with iOS 8 and some critical issues which occurred with Apple’s first iOS 8.0.1 software update on Wednesday, September 24th. A major bug with the HealthKit feature was discovered prior to the iOS 8.0 release, which resulted in Apple pulling all HealthKit enabled apps from the App Store ahead of the public release, leaving 3rd-party devs uncertain as to the fate of their Apps.
If you are a software developer for Apple’s iOS platform you are still recovering from the latest announcements about the future of iOS. There is a lot to digest in regards to the big news for developers and we discuss a few notable highlights. Continue reading Apple to Developers at WWDC: Your Chance to Learn a New Language – Swift
Several Nerds will enjoy what’s become a traditional Memorial Day weekend at Soundset this Sunday, but for the first time there’s an app for that fine festival – and that’s because we built it for our friends at Rhymesayers. Continue reading Long-time listeners, first-time Soundset mobile App makers
Something most people don’t think about is what happens after someone presses the button to release an app into the wild. Development doesn’t always stop, issues crop up, and bugs happen. It doesn’t matter how much testing goes into an app or how many devices someone tested against. There will always be slightly different configurations of phones out there in the hands of real users. Most times, developers need to rely on vague bug reports submitted by users via reviews or emails. Thankfully there is something better we can do to lessen the burden of discovering where those issues are hiding in our apps. There are now tools we can use post-deployment that can track usage and even point us right to the issues at hand. The tool I will be covering today is called Crashlytics.
Crashlytics is a plugin for Android and iOS which is added to your projects via your IDE of choice. You simply download the plugin, add it to your IDE, and then follow the instructions to tie that app to your Crashlytics account. That’s it! You’re then ready to begin receiving analytics for your app. If the app crashes, you get everything from device type, OS version, whether or not the phone is rooted, current memory usage, and much more. The crash itself is detailed with the offending line of code, where it’s located, and if applicable the exception thrown.
The detail given for issues discovered by apps is great, but it gets better. When Crashlytics receives a crash dump it is categorized so the developer can easily sort issues. Crashes with more specificity than others are given higher priority, which means Crashlytics performs a level-of-issue triage for you. It will also lessen the severity of issues automatically if they stop happening for whatever reason. You can also specifically close issues as fixed in Crashlytics once you address them. This can be extremely powerful when coupled with bug-base integration, which is another useful feature of Crashlytics.
Crashlytics can be integrated with many different bug-tracking systems. These include Jira, Pivotal, and GitHub, among many others. In my experience this is one of the most helpful features of Crashlytics . Once a crash is received, Crashlytics automatically creates a bug in your issue tracker of choice and populates it with the relevant information. It will then set the bug’s severity for you – based on the number of crashes detected – and keep it updated. This is extremely helpful and time saving. It takes the burden off of testers and developers of transferring issues from Crashlytics to the bug base and keeping it updated.
These are just some of the powerful features packed into this tool. Another large plus of the tool is that it has become free after Crashlytics partnered with Twitter – they’ve promised to keep developing the tool and add even more features. I hope I have convinced you that discovering and fixing issues post-deployment doesn’t have to be a chore. With the right tools, it can be a relatively easy experience that will benefit users and developers.
Today on the Developer Download we are following up from our webinar Q&A earlier in the week, talking all things nerdy with respect to mobile data. We talk with 3 Nerdery developers who have experienced it all with mobile data. We talk best practices for clients and server, data caching strategies, api security and much more. And now you can watch the Developer Download if you you prefer. Hit the YouTube link provided below!
Host: Andrew Watson
Listen Now: Running Time: 0:35:59 / Subscribe on iTunes
Watch on YouTube: http://youtu.be/f8hK-Fk2Z7k
Our webinar panelists reflect on questions about the makings of a good mobile app from our webinar audience – burning questions we just didn’t have time to address during the live event. Missed the webinar? Let’s take care of that right here then.
Host: Brian Rowe (UX)
Guests: Andrew Watson and Jon Rexeisen (mobile developers) and Jacob Ward (UX)
Consider the mobile apps you use all the time, and the ones you perhaps opened once or twice and then never touch again. There are so many things that factor into such variable quality, utility and popularity – and understanding the difference-makers is critical to anyone who has a hand in creating mobile experiences. Whether you make apps or simply use and/or discard them, this discussion will help you understand the key elements what makes for a successful mobile app.
Hosted by Brian Rowe (UX), this webinar features Andrew Watson and Jon Rexeisen (mobile developers) and Jacob Ward (UX).
Managing strings between iOS, Android and the web is prone to error and hard to manage. When you introduce multiple languages, even more headaches arise.
Twine allows you to keep your localized strings in a central location that can easily be exported to iOS, Android and the web. Twine is great for any multi-platform or multi-language application. It keeps your strings in sync. On a project I’m currently working on, we’re using Twine to consolidate and manage five languages across three different platforms. It’s saved us time and help to cut down on the cost of translations.
Before you begin, make sure that you don’t have any hard-coded strings in your application. This is the first step in localization for any platform and a best practice for mobile development. Make sure to backup your existing strings. Next, you’ll need to install Twine. You can find instructions here: https://github.com/mobiata/twine
After you’ve installed Twine, create a strings.txt file that will be used for storing strings. Twine is able to parse existing string files and write them back to your master data file. Top-level categories can be used to organize your strings, tag attributes for selecting the target platform and comment attributes to give context.
en = Off
tags = ios,android,web
comment = Off
de = AUS seit
es = Apagado
fr = Arrêt
nl = Uit
en = On
tags = ios,android,web
comment = On
de = An seit
es = Encendido
fr = Marche
nl = Aan
en = Edit
tags = ios,android,web
comment = Edit
de = Bearbeiten
es = Editar
fr = Modifier
nl = Bewerken
en = Done
tags = ios,android,web
comment = Done
de = Fertig
es = listo
fr = Terminé
nl = Klaar
The “tags” field is case sensitive and should not include white space. Keep this in mind when generating your strings file.
tags = ios, Android, web
tags = ios,android,web
Running the Twine command will generate you strings files and put them in the correct sub-directories. For iOS, they will be put in the Locales folder and for Android, they will be put in the res folder. You will need to create the corresponding lproj (iOS) and values (Android) folders for each language prior to running Twine. As long as the folders exist, Twine will automatically overwrite the strings files.
To export for Android, put the strings.txt file in your project directory and run the following command. Note: this will replace your existing strings.xml files. Make sure to back up your strings and write them back to the master data file before running this command for the first time.
twine generate-all-string-files "$PROJECT_DIR/strings.txt" "$PROJECT_DIR/res" --tags android
The command to export for iOS is very similar.
twine generate-all-string-files "$PROJECT_DIR/strings.txt" "$PROJECT_DIR/$PROJECT_NAME/Locales/" --tags ios
When you have new text or translations, update your strings.txt file and re-run the commands. All of the string files within your apps will be updated. My preferred editor for viewing the string.txt files is TextMate. Built in text editors like Notepad and TextEdit can have problems opening large string files.
We have used Twine on a number of projects with great success. It’s made managing strings and translations significantly easier. Anyone who is managing strings across platforms or supporting multiple languages should look into Twine.
This challenge is one of a new series of activities that we’re doing within The Nerdery. The goal of this series of quizzes is to give developers a chance to explore portions of the Cocoa API that have a discrete, small scope and that are likely to be less understood.
The requirements for the challenge are as follows:
- Create a view that renders text that looks exactly like the following:
- Center the text block on the screen.
- The text should respond to changes in the operating system’s dynamic type size. When the operating system’s dynamic type size is set to the center, the size should match the screenshot above.
You can assume the presented text has been created according to the following rules:
- All of the text was set in Hoefler Text which ships with iOS 7 at the expected size for the
- The entire text block has been kerned as though someone had typed “-20” into the kerning field in Photoshop
- The line-height has been set as a multiple of the point size.
- Something has been done to modify the type-setting of the numbers. It’s up to you to determine what changed.
I’m making a contest of the challenge. Entries will be accepted up until 2/7/2014. I’ll post my solution to the problem on that Friday and include an article explaining how I approached the problem. All entries will be evaluated by Ben Dolmar and the best external challenge will be announced with the solution article. The winner will receive vast bragging rights and accolades. In addition,
To submit an entry for evaluation, please do the following:
- Fork the project from https://github.com/bdolmar/BRAVO.iOS.Challenge.04Typography.git.
- Post your files to your public fork on Github.
- Send a pull request back to the original repository with your project by midnight on 2/7/2014.
Have any questions? Leave a comment!
This is an interview with Josh Clark to talk about the future of mobile. We had a chance to get him into our recording studio to talk shop about mobile software, and user experiences when he was visiting our campus. We discuss his talk that he gave at the 2013 MIMA Summit as well as the talk he gave at The Nerdery while he was in town. The presentation was called The Seven Deadly Myths of Mobile and you can watch the recording on our blog.
From his site:
Josh Clark is the founder of Global Moxie. Josh is a designer specializing in mobile design strategy and user experience. When he’s not building friendly interfaces, he writes about them. In Josh’s books and blog, he explores humane software, clever design and the creative process. Josh is the author of four books, including Tapworthy: Designing Great iPhone Apps (O’Reilly, 2010), all of which aim to help you harness technology to make your work easier, more beautiful, more awesome.
Josh is a regular speaker at international technology conferences, sharing his insights about mobile strategy and designing for phones, tablets, and other emerging devices.
Host: Ryan Carlson – Tech Evangelist
Guests: Josh Clark (Global Moxie)
Listen Now: Running Time: 0:19:37 / Subscribe on iTunes