Posts Tagged 'Programming'

All About Animation

Just on the off chance you haven’t subscribed to objc.io yet, issue #12 “Animations” is out with the accustomed assortment of must-reads:

Animations Explained goes over the basics of motion, paths, etc.

Animating Custom Layer Properties has particularly clever applications of interpolation functionality: “…by overriding the -display method, we can use those properties to control anything we like, even something like sound volume….”

Custom Container View Controller Transitions goes over how to reusably package up your cool transition code.

View-Layer Synergy gets right down into the guts of how the magic actually works.

Animating Collection Views is great for sussing out how to do layout transitions.

Interactive Animations goes over how to make your animations interactive (most importantly, interruptible) via UIKit Dynamics.

While we’re on the subject of animations, you checked out Facebook’s POP framework yet? Worth a look if you haven’t. Also don’t forget that Canvas library, and the little pieces from the last little while we collected here.

UPDATES:

Adding Bounce to Your UIViews: The Joy of Damped Harmonics in iOS 7 Development

hfossli/AGGeometryKit: “Quadrilaterals on CALayer, CGGeometry-functions, UIView/CALayer properties and other invaluable tools.”

Open Source iOS Library Allowing You To Easily Apply Animated Mesh Transforms To A View Hierarchy — check out math in Mesh Transforms!

Open Source iOS Library Providing Some Nice UIDynamic Based View Controller Transitions

An Open Source Pop Add-On Library Adding A Quadrilateral Property For Amazing Effects

DynamicXray “is a UIKit Dynamics runtime visualisation and introspection library.”

Top 5 iOS 7 Animations as picked by raywenderlich.com

An Open Source Library Providing Many Pre-Built Animations For User Interfaces Built On Pop

Open Source Animation Library Based On Pop Featuring Animation Creation In Storyboards

Multiple Animations

itsmeichigo/ICGTransitionAnimation “is a library to customize transition animation in iOS 7.”

Open Source iOS Component Providing A UIView Subclass That Automatically Bends On Position Changes

VBFJellyView Tutorial

Open Source iOS Component Allowing You To Create Morphing Effects Between Text Label Values

Open Source iOS Component For Morphing UILabel Text Created In Swift

Continue Reading →
0

External Actions: Choosy

One of the mildly frustrating things about iOS programming is that none of the various URL scheme handling schemes have managed to get enough traction to be all that widely useful. But here’s a new one that’s certainly the best put together we’ve seen yet, and we’d strongly encourage everyone to get on board with:

Choosy

People will love your app even more if it helps them use their other favorite apps. We’re essentially solving the iOS’ lack of default app selection mechanism.

Once Choosy is widely implemented, end users will be able to traverse the iOS ecosystem using just the apps they love, be they built-in ones or not…

Screen Shot 2014-05-04 at 7.01.55 AM.png

Thanks to UIApplication’s canOpenURL method and iOS forcing unique url schemes. Basically, we store a list of URL schemes for each app on the server, and categorize apps. Choosy downloads that info as needed.

Choosy caches network data, so the traffic footprint is small. It also instantly knows when a new app from same category is installed, or the default app is deleted, and lets user re-select the default app. Choosy is non-intrusive – if there’s no connection and the default app hasn’t been selected yet, it just opens the default iOS app…

Looks like a big whack of user-pleasing functionality for no particularly large effort. Check it out on github today!

Continue Reading →
0

Asking Pre-Permission

When you open up a new app and a barrage of permissions dialogs pop up at you, doesn’t that just annoy you?

And when a user gets all bent out of shape when something doesn’t work, and it’s because they said no to those permissions in your app, doesn’t that just annoy you?

So yeah, we should all be telling the user exactly why we want a permission, so they’re less likely to say no; and we should be doing it only when we need to, instead of tossing everything at them on first run just to make absolutely sure their first impression of the app is that it sucks. Maybe you’re conscientious enough to have bothered doing that already. For the rest of us, there’s a good article to be reading here:

The Right Way to Ask Users for iOS Permissions

Over time, we’ve learned to ask our users for permission when, and only when, we absolutely need it and we think the user can clearly relate how this access will benefit them.

We’ve re-engineered Cluster using two methods to only show the system permissions dialog once a user has told us that they intend to say “Allow”…

As stated above, the worst possible thing is for a user to deny permission at the system level, because reversing that decision in iOS is very complicated. But if we ask them before the system does and they say no, we still have the opportunity to ask them again in the future when they are more likely to say yes.

For photos alone, 46% of people who denied access in a pre-permissions dialog ended up granting access when asked at a better time later.

This is simpler than you think…

The code described there can be found at clusterinc/ClusterPrePermissions for contacts and access.

And if you want a complete set, check out jlaws/JLPermissions:

An iOS pre-permissions utility that lets developers ask users on their own dialog for calendar, contacts, location, photos, reminders, twitter, and push notification access, before making the system-based permission request.

That cover everything you need permissions for these days? Hmmm … think microphone needs permissions too, recently. Almost a complete set then. No doubt microphone can be left as an exercise for the reader.

h/t: ManiacDev!

UPDATES:

An Open Source Pre-Permissions Framework With Support For iOS 8 Permission APIs

Why 60% of your users opt-out of push notifications, and what to do about it

Continue Reading →
0

Objective-C Builder Pattern

Well, here’s one of those too obvious to think of — too obvious for us until it was pointed out, anyways — clever programming tricks everyone should adopt: No doubt if you have any non-trivial data model, you’re using something recognizable as the Builder pattern to construct those objects. (And if you’re not, your code’s probably a complete mess, and you should be.) But there’s room for a good bit of error with variable scope, copy paste muck ups, and the like.

Enter this clever spark Klass Pieter, for whom obvious solution is obvious:

The Builder Pattern in Objective-C

… In order to make this pattern fit Objective-C we’re going to apply another pattern. This one comes from Ruby. I don’t know what the official name for it is, I just call it the Ruby configuration block pattern. This is our final idiomatic Objective-C implementation:

Pizza *pizza = [Pizza pizzaWithBlock:^(PizzaBuilder *builder]) { 
   builder.size = 12;
   builder.pepperoni = YES;
   builder.mushrooms = YES; 
}];

We made the interface fluent, the scope of the builder is limited to within the block and as an added benefit the call to build is now implicit. When the block returns the pizzaWithBlock: method knows that configuration is finished and can call build for us. Not only did we make the pattern idiomatic Objective-C, we also removed one of the Java implementation’s major headaches; forgetting to call the sentinel method…

As you may have noticed here and there, we’re big believers in making our code readable and foolproof. And this is a pretty nice advance on that front from our current builder pattern type of practices, yep.

And this Joris Kluivers fellow here was not only as struck with the elegance here as we are, he went ahead and started implementing it:

The Builder Pattern in Objective-C Foundation

In a recent blog post Klaas Pieter Annema wrote about using the builder pattern in Objective-C. Inspired by his post I created two categories that bring similar functionality to NSURL and NSDate.

An example:

NSURL *url = [NSURL URLWithBuilderBlock:^(NSURLComponents *builder) {
  builder.scheme = @"http”;
  builder.host = @"joris.kluivers.nl”;
  builder.path = @"/blog/2014/04/08/the-builder-pattern-in-objective-c/";
}];

My builder categories on NSDate and NSURL are available on github for review. Let me know what you think.

Nice examples there of how exactly to go about implementing this for your own objects.

h/t: ManiacDev!

Continue Reading →
1

Bézier Path Construction

Most excellent article here on conceptualizing how to put together those Bézier path thingamabobbies in code, with by leaps and bounds the best explanation we’ve ever seen of how curves work:

Thinking like a Bézier path

… Once you’ve learnt to break down one path you can apply the same tools and divide it into lines, arc and curves. One by one, in any combination. The more you do the better you’ll get at it. But we missed curves and curves are awesome. Curves are the center of you favorite vector drawing program. They draw a curved line to another point, bending towards two “control points” on its way there. I said bending towards because the curve doesn’t go all the way to neither of the two control points.

There is a little bit of math involved in how the path is drawn between the four points (the start point, 2 control points and the end point) but unless you are interested you will never have to use it. I am interested so I will gladly explain the math. Feel free to skip ahead if you are afraid that you might learn something…

Master that fear and read the whole thing!

h/t: iOS Dev Weekly!

Continue Reading →
0

Cross-Platform Mobile Library Development

If you actually need any of the information we’re relaying to you today, our deepest sympathies; but if you are so bedevilled as to have to come up with some plan that makes sense for developing a cross-platform native-requiring library, the nice people at Skyscanner have done an impressive amount of legwork researching and documenting the alternatives for you. Shocking spoiler: They all suck.

Developing a mobile cross-platform library – Part 1. Exploring

Here, I am including the experience I had while exploring solutions for developing a mobile cross-platform library, i.e. a single codebase that could be part of mobile apps running under different platforms. It covers my journey from mobile cross-platform developments tools (PhoneGap, Titanium, and the likes), code porting tools, and WebViews that weren’t up to the task, to C++ and JavaScript engines that did work. There aren’t many resources out there explaining how to approach this problem, so we thought it could be helpful if we shared this experience. This is the first of three parts, which lists all the explored solutions…

TL;DR: C++ sucks the least.

Developing a mobile cross-platform library – Part 2. C++

When the cross-platform development tools failed to provide the functionality we needed (check part one), we decided to try a lower-level solution that is supported by both platforms; C++. In Android, we’re able to interface C++ code through the Android Native Development Kit (NDK) and the Java Native Interface (JNI) framework. As for iOS, this is possible with Objective-C++, a language variant that allows source files to include both Objective-C and C++. Hooray!!

There’s also a promised third part on embedding JavaScript along with an engine, which is the other option that part 1 found to suck little enough to still be somewhat workable; but that seems to us more than a little ridiculous for the library development case … and if you’re doing a full app, well we’d say in that case the choice narrows right down to Apportable!

h/t: @binpress!

Continue Reading →
0

Barcodes for iOS 7

Here’s a book you might think about picking up, written by Oliver Drobnik:

Barcodes with iOS 7: Bringing together the digital and physical worlds

Barcodes are a universally-accepted way to track and share information about products, applications, and businesses. Until recently, however, it’s been difficult for iOS developers to take advantage of them without licensing complicated or expensive third-party libraries. With iOS7, Apple has added all the necessary components for you to make apps that scan, display, and print barcodes.

Barcodes with iOS 7 is the first and only book that comprehensively addresses barcode technology for the iOS developer. It offers a introduction to commonly used formats, such as ISBN and UPC codes and provides real world examples that teach you how to integrate code scanning and generation into your apps. This book consolidates information about applicable Apple frameworks in one place so you can quickly add native barcode support to your existing enterprise apps or start building new apps that help bring together the physical and digital worlds…

drobnik_cover150.jpg
  1. Barcodes, iOS 7, and You – FREE
  2. Media Capture with AV Foundation – AVAILABLE
  3. Scanning Barcodes – AVAILABLE
  4. Passbook, Apple’s Digital Wallet
  5. Generating Barcodes
  6. Getting Metadata for Barcodes
  7. Putting Barcodes in Context

And you get a 1D support library for free, too:

iOS 7 does not support generation of 1D barcodes. Still I wanted to have a modern and powerful way to have this functionality present in this book which is all about all types barcodes. So you are getting the most current version of BarCodeKit completely for free. As long as you own a copy of the book in any form you can use BarCodeKit to create 1D barcodes in all your apps…

Still teetering? Buy right now for a half off deal:

Now through March 9th18th you even get 50% discount with promo code “mldrobnik”“bwiaunch50!”

So there you go, if you’ve got any interest in hooking up your apps with real world stuff, looks like a pretty darn solid investment there!

Continue Reading →
0

iOS Design Central

Here’s a new place to bookmark for your designer friends, or yourself should you fancy yourself a designer: Apple’s pulled together all their various design resources onto a new page

Desiging Great Apps

Exceptional user experience is a hallmark of Apple products, and a distinguishing feature of the most successful apps built for iOS and OS X. Use the resources below to learn how to build the polished, engaging, and intuitive apps that Apple customers expect…

Indeed. Don’t think there’s actually anything new there at the moment, seems to be WWDC videos and previously released documents pulled together in one place, but no doubt a good place to keep an eye on in future.

It’s also been quite a while since our last design roundup post back when iOS 7 was a polarizing novelty, so let’s see what else is new we haven’t tacked on to its updates since:

Pixel Perfect Precision Handbook 3 is out now (h/t iOS Dev Weekly), that should be on every designer’s must-read list.

This is a pretty nifty iOS 7 UI Kit Photoshop Action Set:

You’ve probably seen many iOS 7 UI Kits. But this one is slightly different, as there is no psd file involved. All you need (apart from love) is this little 1.4 MB .atn file that creates entire default look iPhone mockups for your wireframes, design mockups (use it with care) or just quick ideas…

iOS Dev Tools is an ever more comprehensively curated set of links in all categories of development interest we don’t think we’ve got around to linking to before, for design-related stuff check out these sections:

Check out all the non-design categories while you’re at it, and follow @iOSDevTools for updates!

UPDATES:

30 Amazing iOS 7 UI Kits – Part One

Continue Reading →
0

Background Fetch Caveats

Couple interesting posts lately about background fetch resource usage. If you’re not familiar with background fetch, that’s an iOS 7 thing that’s explained quite nicely in objc.io’s Multitasking in iOS 7 article:

Background Fetch is a kind of smart polling mechanism which works best for apps that have frequent content updates, like social networking, news, or weather apps. The system wakes up the app based on a user’s behavior, and aims to trigger background fetches in advance of the user launching the app. For example, if the user always uses an app at 1 p.m., the system learns and adapts, performing fetches ahead of usage periods. Background fetches are coalesced across apps by the device’s radio in order to reduce battery usage, and if you report that new data was not available during a fetch, iOS can adapt, using this information to avoid fetches at quiet times…

But the naîve user may find a surprise in wait:

An Unexpected Botnet

… There is, however, an intrinsic danger in applying this ability without fully thinking through the implications. When enabled within your applications you are essentially building a massively distributed botnet. Each copy of your application will be periodically awoken and sent on a mission to seek and assimilate internet content with only the OS safeguards holding it back. As your app grows in popularity this can lead to some rather significant increases in activity…

Here are the feed request frequencies for various Background Fetch enabled podcast clients … For an RSS feed that changes only once per week just these apps produce 126k web requests each week (out of 160k across all aggregators ). The feed itself is 450KB (49KB gzipped). Where it not for HTTP caching/compression (discussed later) this would be generating 56GB of almost entirely unnecessary downloads each week…

That is, indeed, a lot of almost entirely unnecessary downloads. The developers of Castro chimed in here:

The Value of Background Fetch [Point]

… Our strategy with Castro has been to employ Background Fetch to help us avoid the ongoing cost of a server. Castro polls each subscribed feed from the app regularly and posts local notifications when new episodes are found. There are pros and cons to this approach.

Pros

  • We spend no time on web app development or money on server hosting. Xcode is always open.
  • We have no scaling concerns.
  • The continued functionality of the app is not dependent on future sales.
  • There are fewer points of failure.

Cons

  • Worse update performance since the app hits every individual feed, rather than one centralised server.
  • A central server gives developers flexibility to fix individual feed issues, like poorly formatted dates or duplicate episodes for example…

Well, being big believers ourselves in not doing work we don’t have to, that makes a pretty compelling argument, indeed. But hark! Here’s a counterpoint from coming soon Castro competitor Overcast author Marco Arment:

The Value of Background Fetch [Counterpoint]

… Service-backed apps still have a lot of advantages and exclusive capabilities over iOS 7’s Background Fetch. I think server-side crawling is still the best choice for podcast apps and feed readers, for which users want fast updates to collections of infrequently updated feeds.

Overcast has been crawling tens of thousands of podcast feeds every few minutes for the last 6 months using standard HTTP caching headers. In the last week, 62% of all requests have returned 304 (“Not Modified”). Many of the rest returned the entire “new” feed, but none of the episodes had actually changed, making the server download and process hundreds of kilobytes unnecessarily.

An app using Background Fetch needs to make all of those fruitless requests just to get the handful of occasional changes. All of those requests cost processor time, memory, battery power, and data transfer. And each copy of the app needs to download those hundreds of wasted kilobytes when a server erroneously reports an unchanged feed as new…

A server can simply send a silent push notification to all subscribed apps when there’s new data in a feed, and each app can download just the changes. With infrequently updated feeds, like podcasts, this leads to huge savings in battery life and transferred data over time…

Well, there’s that too. So yeah, if you can’t count on decent 304 support, background fetch is not your resource-optimal choice no.

Lots of good numbers to crunch through, so read the whole posts. Personally, if the choice for your particular application is less than immediately obvious, we’d recommend implementing both methods; that way, if your service goes down, or you stop paying for it, or whatever, the app can remain functional. Safety first and second, that’s us!

UPDATES:

Apropos of things to do to avoid users calling out your app as battery-hogging, take a gander at The Ultimate Guide to Solving iOS Battery Drain

Continue Reading →
0

All About Strings

Are you reading objc.io? If not, you should be. Check out issue #9 for more than you ever realized you didn’t know about strings. Yes, strings.

Quick now: How do you correctly find the length of a string containing odd characters like emoji? And how can you be certain you’re comparing strings with combining characters for visible equivalence correctly? If the answers don’t spring to mind, check out NSString and Unicode.

How do you correctly, i.e. locale-aware, join a list of items for text display? That’s one of the many tidbits in Working with Strings.

No doubt you know how to use localized .strings … but did you know in iOS 7+ you can do locale-aware plurals with .stringdict files? And do you know how to correctly display a localized file name? See String Localization.

Need to validate your input? Or have a full expression grammar? Check out String Parsing.

Finally, know how to calculate bounding rects for attributed strings in the new non-deprecated iOS 7 way? And how to lay out hanging indents for lists and decimal-aligned number tables with Text Kit? If not, here’s String Rendering to get you up to speed.

Haven’t seen a developer periodical this consistently high quality through issue #9 since … well, ever, actually … so we strongly encourage you all to subscribe with their app to keep the goodies coming!

UPDATES:

Extending “strings” to include “text” — Open Source Library And Editor Tool For Easily Formatting Text Within Your Apps

Continue Reading →
0
Page 3 of 89 12345...»