Archive

Tag Archives: iOS

Change are if you are using Swift for more then “Hello World” you will need to interact with existing Objective-C libraries such as FMDB, FCModel, MMWormhole, or something similar.  Although Apple has come great documentation and there is a WWDC video discussing this I thought it might be helpful to walk through my experiences as someone new to Swift.

As I do most of my mobile development around the native aspects of the Titanium framework, I thought it would be interesting to explore writing native extensions in both Objective-C and Swift.  So as part of the Ti.Wormhole project, I provided examples in both languages.  Since the MMWormhole project which Ti.Wormhole is based upon is written in Objective-C, a bridging header is required to talk between the Swift extension and the wormhole.

The first step in creating the bridging header is to add a header file to your project.  This is just like adding any other header file, just using the [MyProjectName]-Bridging-Header.h naming contention.  If you haven’t done this before, in Xcode select File –> New –> File… from the menu then select Header File as shown below.

create-h

Then press Next and enter the name of your bridging header. This needs to be done in the [MyProjectName]-Bridging-Header.h, in the following screenshot this is shown as TodaySwift-Bridging-Header to match our extension name.  If you have multiple targets like in the WormholeExample project you will want to select the correct Target or Targets to apply.  I also found that the bridging header likes to be in the root of your project, so would recommend avoiding placing the file in a nested directory.  After verifying your Targets, Naming, and placement, press the Create button to continue.

create-header

You will now have a file with contents similar to the below.  To allow Swift to access your Objective-C libraries you just need to #import the headers for your libraries as shown below with the MMWormholeClient.h.

bridge-header

Next you will need to update your Target’s Build Settings to reference your Bridging Header.  This is done by opening the Building Settings tab in Xcode and scrolling down to the Swift Compiler section.  Here you want to update the Install Objective-C Compatibility Header option to Yes and enter the name of your Bridging Header file into the Objective-C bridging Header option as shown below.

build-setting

You are almost ready to start using your Objective-C libraries from Swift.  The very last thing you need to do is import Foundation at the top of the Swift file you are using to reference Objective-C.  This is demonstrated in the example project Swift file here and illustrated in the screenshot below.

import

JavaScript style events are one of the features I miss most when building native applications.  The fact that Titanium allows for this on mobile is one of things I enjoy most about the platform.  When Appcelerator introduced the ability to create native extensions in version 3.5.x, I began to explore how to pass information through between native iOS extensions and a Titanium application.

In the native world, Mutual Mobile solved this with their MMWormhole project.  MMWormhole uses the Darwin Notifications and your application’s shared directory to pass messages between your app and your extensions.  This seemed exactly what was needed to create events between your Titanium app and extension (or Watch Apps).

After some experimentation and hacking, a Titanium friendly version of MMWormhole called Ti.Wormhole as created.  This allows for events to be published/subscribed between native extensions and your Titanium app.  This is done through a native Wormhole client that you add to your native extension communicating with a native Titanium module installed within your app.

Ti.Wormhole in Action

The following video shows a quick walk through of the Ti.Wormhole running in the iOS simulator.

Before you get started

Before you get started, this development approach requires you program largely in native ( Objective-C or Swift ).  So if you are not comfortable in Xcode, you might want to explore another alternative.  Next, you will need a nightly build of Titanium 3.5.x or greater.

How does it work?

The mechanics are of Ti.Wormhole are straightforward.  Messages are passed from MMWormhole in your Titanium app using a native module to your native extension.  In your native extension another version of MMWormhole  receives your messages providing you the information passed from your Titanium app.  All Ti.Wormhole really does it make MMWormhole work nicely with Titanium.

overview

Native Extension to Titanium

The process of sending events from your native extension to Titanium is relatively straightforward.  First you need to create your native extension… and yes you do this completely native without any JavaScript or Titanium helpers.  Next add the MMWormholeClient classes to your project.  These will give you all of the helpers you need to talk to your Titanium app.  Next you add the Ti.Wormhole module to your Titanium project. This enables your Titanium project to end/receive notifications.

Native to Titanium

Your native extension will publish notifications that will later be turned into Titanium JavaScript events.  The following diagram illustrates the end to end process for doing so.

native-to-ti

A diagram is great but how does this actually work?  Well… to broadcast events from your extension to a Titanium app the first thing you need to do is to create an instance of the MMWormholeClient class.  This class is one half of the bridge you need between your Titanium app and extension.  The below shows how to create this class in both Objective-C and Swift.  The key thing to remember, is the GroupIdentifier and Directory need to match the parameters use by the Titanium module. Otherwise your messages will not be received.

Objective-C Example:

objc-init

Swift Example:

swift-init

Next your native extension needs to send a notification. This is done using the passMessageObject function of the MMWormholeClient class.  The important thing to remember here is that the identifier provided, needs to be the same as the event you are listening to in your Titanium app.  In the below example we are broadcasting to an event named wormEvent.

Objective-C Example:

objc-post

Swift Example:

swift-post

That is all we need to do from our native extension, the rest will be done in our Titanium app.

The first thing we need to do in our Titanium app is to require an instance of the Ti.Wormhole module.


var wormhole = require('ti.wormhole');

Next we use the start method to configure the module to interact with the MMWormholeClient class in our native extension.  The key thing to remember here is that the suiteName and directory need to match the parameters used to create the MMWormholeClient class instance in your extension.

wormhole.start({
      suiteName:"Your suite identifier",
      directory:"Your message directory"
});

Finally, you just need to use the addWormhole method to create an event listener.  This will listen for a specific event and generate a callback when it is triggered.

wormhole.addWormhole("wormEvent",function(e){
    console.log("Event in ti app: " + JSON.stringify(e));
});

Titanium to Native

It is just as easy to go from Titanium to Native.  The following diagrams the end to end process that is used in sending messages from Titanium to your native extension.

ti-to-native

I know what you are thinking, another diagram great, show me the code.  To save time we will skip over the requiring the Ti.Wormhole module and calling Start method. This would be the same as the Native to Titanium example.

The first step is to send a message from Titanium using the Ti.Wormhole module’s post method as shown below.  Since you will want to background your app and access notification center, you might want to use setTimeout to give yourself a few seconds.

setTimeout(function(){
     wormhole.post("wormEvent",{displayNumber:displayCount});
},10000);

By calling post, a message is placed into the notification queue to be picked up by your native extension.  To receive these notifications you need to add a listener in your native extension as shown in the following Objective-C and Swift examples.

Objective-C Example:

objc-listen

Swift Example:

swift-listen

Examples

The Ti.Wormhole project has examples written in both Objective-C and Swift.  You can see video overview of the project here.  Everything else is at https://github.com/benbahrenburg/Ti.Wormhole.

Lately I’ve been experimenting with using Swift in my Titanium projects.  Since Titanium is really just a Objective-C app under the covers it is fairly straight forward to mix and match Swift within your project.

I did encounter one surprise the first time I added a Swift module or extension to my project.  Even though the extension or module compiles without issue, as soon as it was added to my Titanium project I started to receive errors similar to dyld: Library not loaded: @path/libswiftCore.dylib.  The root cause was surprising, it seems that Xcode 6.2 does not enable the “Embedded Content Contains Swift Code” Build Setting by default for Swift extension projects.

If you are building Swift extensions for Titanium or any other Objective-C application make sure you update your project to include this.  To do this, go to your Swift Target’s Build Settings, then Build Options.  Alternatively you can just search for embed to find the correct option.  Once you have located the setting you need to toggle the “Embedded Content Contains Swift Code” from No to Yes as illustrated below.

xcode-swift-embedded

It seems every app has its own way to handle Geo Location.  In many of my cases, your destination is more important then your journey. In iOS 8 Apple provides the CLVisit API specifically designed to provide this type of functionality.  Events are generated when you arrive to a location, and another is generated when you leave.  This provides a very battery friendly approach to solving place based Geo Location problems.

So how do you use this in Titanium?  Like almost any other Titanium requirement you run into there is a module already available.  You can download the Ti.GeoVisits module to use this functionality today.  I used the example app.js for a week and found that the Visit event fired reliably after I was in a single location for more then 10 minutes and about 5 minutes after leaving a location.  This wait time does cause for quick stops such as picking up take away to be missed.  Although this approach has trade offs, it virtually has no impact on battery life.

Below is a record of my tests over the last 9 days.  I’d encourage you to try the same test yourself.  As simulator testing isn’t really a meaningful option for Geo Location apps, I would suggest installing the example app.js and heading out to do a few errands.

Results for the last 9 days:

IMG_0214

What does the Ti.GeoVisits API look like?

The full Ti.GeoVisits API is very small consisting of only three methods and four events.  The below snippet summaries all of these.  For full documentation please visit here for details.

var visits = require('ti.geovisits');
//Fired when Ti.GeoVisits starts
visits.addEventListener('started',function(e){});
//Fired when Ti.GeoVisits stops
visits.addEventListener('stopped',function(e){});
//Fired when Ti.GeoVisits errors
visits.addEventListener('errored',function(e){});
//Fired when Ti.GeoVisits registers a place visited or left
visits.addEventListener('visited',function(e){});

//Boolean indicating if module supported
visits.isSupported()

//Method used to start monitoring for visits
visits.startMonitoring();

//Method used to stop monitoring visits
visits.stopMonitoring();

Learn more about Ti.GeoVisits on Github at https://github.com/benbahrenburg/Ti.GeoVisits.

You can also download the module GitTio at http://gitt.io/component/ti.geovisits

How to use Charts on mobile is one of those areas where everyone has an opinion.  Usually these approaches boil down to the use of a WebView or taking a dependency on a 3rd party native framework.

Usually I recommend using a WebView as the web charting tools tend to provide a greater level of functionality. But recently I discovered JBChartView by Jawbone which changed my mind.  JBChartView  provides charting functionality I typically use bundled in an easy to use native iOS (sorry not android version) project.

To make JBChartView consumable by Titanium I’ve wrapped the project into a module, Ti.JBChart , and created Titanium specific documentation and examples.  The below animated gif shows the Ti.JBChart examples in action.

In Action

An example

The Ti.JBChart  github project has examples for Bar, Line, and Area charts.   The following snippet shows an example on how to use the LineChartView in your Titanium project.

    function createData(){
        var result =[];
        function createRandom(min,max){
            return Math.floor(Math.random()*(max-min+1)+min);
        }   
        for (var iLoop=0;iLoop<12;iLoop++){
            result.push(createRandom(1,12));
        }
        return result;
    }

    var data = [];
    //Add first line chart
    data.push(createData());
    //Add second line chart
    data.push(createData());

    var myStyles = [];
    //Create the first line chart with a solid  line
    myStyles.push(chart.CHART_LINE_SOLID);
    //Create the second line chart as a with a dashed line
    myStyles.push(chart.CHART_LINE_DASHED);

    var lineChart = chart.createLineChartView({
        width:Ti.UI.FILL, height:250, 
        data : data,
        toolTipData : ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'],
        selectedLineColors :['yellow','orange'],
        lineColors:['green','blue'],
        styles : myStyles,
        selectionBarColor:'purple',
        chartBackgroundColor:'#404041'
    });

 

Looking for more?

Starting with Titanium 3.3.0.GA Appcelerator has updated their module templates to have a new default folder structure.  Along with these directory changes you will notice that you get a permission error when running the ./build.py script, usually something like the error shown below.

build-1

To fix this you simply need to run the chmod 755 build.py command in terminal as shown below.

build-2

This updates build.py to have the correct permissions so that you can continue your building by running build.py as you’ve always done.

build-3

Since the release of iOS7, the Live Blur effect has been extremely popular.  Since Apple doesn’t yet provide this effect natively the community has come up with a few different approaches to achieve this effect.

Toolbar Layer

One common approach to achieving a live blur is to use a layer from the UIToolbar.  This allows you to use the same live blur effect that a IUToolbar has, but with the same functionality of a UIView.  This approach is reliable with good performance.  The downside, is you have no control over the Blur and in iOS 7.1 the blur was made softer making it difficult to see when used in come color schemes. Adrian  Opaladini has created an excellent Titanium module called Live BlurView which implements this approach. If you are looking at implementing a light live blur I highly recommend checking out this module.

Timer Driven

The next approach to implementing a live blur effect is to use a timer and a blur algorithm or library such as GPUImage.  Typically this is implemented using a timer which at a specific duration takes a snapshot of the source view and applies a blur effect.  As you can imagine the downside to this approach is you need to implement the refresh code yourself.   This usually requires managing the processes of a timer, view snapshot, and image processing.  Not a ton of code, but you don’t get anything out of the box. The upside, is complete control over the process.  This allows you to use the blur effect that looks best in your app, at a frequency that makes sense. There is an example of how to do this using the Ti.BlurView module here.

Another Option…

I really wasn’t happy with either the Toolbar or Timer approaches.  I wanted more control then I had with the Toolbar approach, but the idea of firing a timer when it wasn’t needed wasn’t appealing, especially considering the performance impact.  This got me thinking, that for many Titanium apps, the UI fires all types of events when the application state has changed.  Why not hook into these events. Out of this came the Scroll Blur example for the Ti.BlurView module.

See it in action

ScrollBlur

The Code

var mod = require('bencoding.blur');
	
exports.createWindow = function(){	

	var win = Ti.UI.createWindow({
		backgroundColor:'blue',
		barColor:"#999", title:"Blur on Scroll"
	});

	function createRows() {
	
	    function buildRow(el) {
	        var row = Ti.UI.createTableViewRow({
	            width:150, height:120
	        });
	
	        var headerImage = Ti.UI.createImageView({
	            image: el.image, 
	            width:Ti.UI.FILL, height:Ti.UI.FILL
	        });
	
	        var titleLabel = Ti.UI.createLabel({
	            text: el.title,
	            width: Ti.UI.FILL, height: '30dp', 
	            color:'green',
	            horizontalWrap: false, bottom: '5dp', 
	            left: '5dp', right: '5dp',
	            font: {
	                fontSize: '20dp', fontWeight:'bold'
	            }
	        });
	
	        row.add(headerImage);
	        row.add(titleLabel);
	        return row;
	    };
	
	    var rows=[];
	    for (var iLoop=0;iLoop<100;iLoop++){
	        rows.push(buildRow({ title: 'Test Row '+iLoop, 
	        					image: 'cat.jpg'}));
	    }
	    return rows;
	};

	var list = Ti.UI.createTableView({
	    width:Ti.UI.FILL,  height:Ti.UI.FILL, data:createRows()
	});
	win.add(list);

	var imgView = mod.createGPUBlurImageView({
		height:250, width:Ti.UI.FILL, zIndex:500,top:0,
		blur:{
			type:mod.IOS_BLUR, radiusInPixels:1
		}		
	});
	win.add(imgView);	

	var w = Ti.Platform.displayCaps.platformWidth;
	var blur = {
		timerId: null,
		apply : function(){
			Ti.API.debug("Taking screenshot");
			var screenshot = list.toImage();
			Ti.API.debug("applyBlur : Cropping screenshot");
			screenshot.imageAsCropped({x:0,y:0, height:250,
										width:w});
			Ti.API.debug("set screenshot as image to ImageView");
			imgView.image = screenshot;
			Ti.API.debug("set blur so we will update");
			imgView.blur={
				type:mod.BOX_BLUR, radiusInPixels:5
			};	
			Ti.API.debug(" Done with Blur");				
		}		
	};
		
	list.addEventListener('scroll',function(f){
		Ti.API.debug("action fired : scroll");
		
		if(blur.timerId!=null){
			Ti.API.debug("Timer already set, returning");
			return;
		}
		
		blur.timerId = setTimeout(function(){
			blur.apply();
			blur.timerId = null;	
		},50);	
			
	});

	list.addEventListener('scrollend',function(f){
		Ti.API.debug("action fired : scrollend");
		
		if(blur.timerId!=null){
			Ti.API.debug("Clearing Interval");
			clearInterval(blur.timerId);
			blur.timerId = null;
		}
		blur.apply();	
	});
 	 		
	win.addEventListener('open',function(f){
		blur.apply();
	});

	win.addEventListener('close',function(f){
		if(blur.timerId!=null){
			clearInterval(blur.timerId);
		}	
	});
		
	return win;
};
Follow

Get every new post delivered to your Inbox.

Join 1,235 other followers