ENTRIES TAGGED "ios"
Part One: Easily find Chromecast devices on your local network
Now that Google has opened up the Chromecast API for anyone to play with, it’s possibile to create iOS applications that can leverage the $35 device as a way to display to HDMI devices wirelessly. In this series of tutorials, we’ll go over the API, starting with configuring your project to use the framework, and finding devices out on your local network to play with.
Let’s assume you’ve set up a Chromecast device attached to an HDMI TV and have it configured for your local network. Now it’s time to get an App set up to use it. We’ll use the iPhone Simulator in these examples, since it can talk to Chromecast devices just like a physical device, as long as the Mac you are developing on is on the same LAN as the Chromecast dongle.
Begin by creating a project, as usual. For this example, I used a single-view Storyboarded app. I set up an
UITableView inside the default
UIView, hooking it’s datasource and delegate to the default view controller the wizard had created. Next, I went to the Google Google Cast API page and downloaded the iOS framework, then used the “Add Files…” project option to add the framework to the project, copying in the files.
RYO small floating view containing any interface you like
Of all the new features and APIs that iOS 7 provides to developers, none, in my opinion, is as important from a user interface perspective as custom view controller transitions, the ability to insert your own animation when a view controller’s view takes over the screen. Thus:
- When a tab bar controller’s child is selected, you can now animate the change.
- When a view controller is pushed onto a navigation controller’s stack, you are no longer confined to the traditional “slide in from the right” animation.
- When a presented view controller’s view appears or is dismissed, you are no longer confined to a choice of the four
In the third case — a presented view controller — iOS 7 introduces a further innovation: You can position the presented view wherever you like, including the possibility of only partially covering the original interface.
In other words, the presented view controller’s view can float on top of, and partially reveal, the original view controller’s view; the user sees the views of both view controllers, one in front of the other.
Mobile developers to gain a new set of platforms for their apps
One of the perennial technologies that regularly appears at the Consumer Electronics Show is the smart TV set, but they never seem to gain the kind of traction that the manufacturers hope that they will. This may finally be coming to a end, however, as a new generation of smart TVs are poised to enter the market. Even Apple is finally supposed to release their own products in this space this year. And when these hyper-aware TV sets enter the Internet of Things, they are likely to do it running mobile operating systems.
The reasons for this are several. From a purely economic standpoint, the margins on televisions don’t really afford room to pay for a full-blown desktop operating system license, nor the hardware required to support a rich desktop environment. It’s also unclear that anyone would want to run Microsoft Word or other general types of software on their TV. While a free operating system such as a desktop Linux OS might fit the bill, especially since it is famous for being able to run on a meager amount of hardware, it is equally unclear if it will be able to run the software that manufacturers and users are going to want to see on a TV.
All predictions are for entertainment purposes only!
It is a generally accepted requirement that all technology pundits attempt a yearly prognostication of the coming 12 months. Having consulted my crystal ball, scryed the entrails of a falcon, and completed a 3 day fasting ritual in a sweat lodge set up inside a Best Buy, I will now tempt the Gods of Hubris and make my guesses for the year in mobile.
Targeting the highest common denominator
Some would claim that native is the best approach, but that looks at existing WORA tools/communities, which mostly target cost saving. In fact, even native Android/iOS tools produce rather bad results without deep platform familiarity. Native is very difficult to properly maintain in the real world and this is easily noticeable by inspecting the difficulties we have with the ports of Codename One, this problem is getting worse rather better as platforms evolve and fragment. E.g. Some devices crash when you take more than one photo in a row, some devices have complex issues with http headers, and many have issues when editing text fields in the “wrong position”.
There are workarounds for everything, but you need to do extensive testing to become aware of the problem in the first place. WORA solutions bring all the workarounds and the “ugly” code into their porting layer, allowing developers to focus on their business logic. This is similar to Spring/Java EE approaches that addressed complexities of application server fragmentation.
UI dynamics, multitasking, maps, and more
iOS 7 is here and we are all very excited. But, as programmers, this isn’t a time to celebrate. This is a time to be concerned. About what, you ask? API Differences is all I can say. How does iOS 7 affect our apps and what is there for us to learn? The iOS SDK is a huge collection of APIs and many of us won’t have time to play with all of the APIs. So we need to be selective about what APIs we use and how efficiently we plan to use them. In this post, I’m going to briefly tell you about some of the new APIs that you need to keep an eye on in iOS 7.
Additions to iOS 7
These are all the Dynamics APIs that Apple has added to UIKit. Start by learning about the UIDynamicAnimator class and take it from there. That is the key to UI Dynamics.
Sometimes earth changing moments come in fingertip-sized packages
Well, the media feeding frenzy that is an Apple product release press conference is over, and the whelmingness is definitely on the under, rather than over side. Part of the lack of drama is that, these days, it’s almost impossible for Apple to keep anything under wraps. There are just too many hands in the supply chain, too many carriers to coordinate a launch with, and too many opportunities for a stealthy cameraphone snapshot of a box or component. Add in patent and FCC filings, and your barber can tell you what’s going to be unveiled, at least a week or less from the event.
Even a great development environment has room for improvement
As the not-so-mysterious September 10th Apple event approaches, it’s widely anticipated that the final version of iOS 7 will be released at the same time. Along with it will come a new version of XCode. While XCode is a pretty awesome development environment (in my opinion, at least), there are a few things that just irk the heck out of me. So, if anyone at Apple happens to be listening, here’s my laundry list of things I’d like to see fixed.
Long a development tool, TestFlightApp wants to move into analytics
For most iOS developers, TestFlightApp has become the go-to tool when they want to distribute a development build to testers. For those not familiar with the site, you can register applications, and then upload IPA files signed with either a development or AdHoc profile, either manually or using a desktop app that integrates directly into XCode.
Once uploaded, your testers can be automatically notified via email that there is a new version of the app available, and download it directly onto their device without having to use iTunes. It can even capture device IDs for new users (or new devices for existing users), and export them for use in the Apple developer portal.
You can also add code to have the running app check in with TestFlight. You can add “checkpoint” flags, ask survey questions (“why did you come to this page”), and have console logs and crash reports automatically uploaded to the site.
The problem is, once you’re ready to ship a production version, you have traditionally had to turn everything off and make sure that the Test Flight library was not linked in to the app. This has meant that there was no way to capture crash data from customers running the app. But now that’s changing.
Recently, TestFlightApp announced that it was now OK to leave the library in copies of your app uploaded to the App Store, and to have the app check in with TestFlight. Why the change? Probably because it is needed to support FlightPath, their new analytics tool. FlightPath seems to want to be the Google Analytics of mobile, allowing developers to see how customers use their app and offering demographic data.
FlightPath is likely to be the path that TestFlightApp takes to start monetizing their service. TestFlightApp has always been free, but there has been no pronouncement about whether FlightPath will follow that same model. It is currently in an open beta, so we may have to wait and see what the pricing model for the final product is. Of course, by then, all those beta users will have become hooked.
One major caution for people intending to keep TestFlight in their production code, watch out for leakage of private data! Many test builds spit out tons of information to the console. At times, I’ve had everything going back and forth to a server dumping itself onto the log. If you don’t disable that in the shipping code, you could be accidentally capturing all sorts of sensitive data, including credit cards, HIPPA restricted information, etc. So make sure that you have compiled out (or disabled) anything like that in the production build (which you can test with an AdHoc profile.)
Great hacks, great responsibility
This week, we’re going to depart from the basics, and talk about a piece of Objective-C black magic that, when used properly, can be a powerful tool. However, used incorrectly, it can cause devastation on a biblical scale. Let’s talk Method Swizzling.
Image that you have an app just about ready to go into the store, and your UI designer suddenly decides that all the
UIButtons should use a different font. Unfortunately, you have hundreds of them scattered over dozens of XIB files. Sure, you could go through and change each one by hand, but what happens if he changes his mind again?
Wouldn’t it be nice if you could programmatically force all the
UIButtons in your app to use a new font? Maybe we can do it with a category? If we override the
initWithFrame methods of
UIButton, we can call
super and then set the font explicitly, right? Unfortunately, no, because
super isn’t available in an overriden category method. But there is a way we can do it, using swizzling.