Tag: iOS

I am embarking on a series on Developing for the Microsoft Band. If you are not familiar with the Band it is a product that is in its second iteration. With 11 sensors ranging from accelerometer and gyroscope to heart rate and skin sensor, the Band is a great device.

The first part of the series we will be looking at Web Tiles. Microsoft Band Web Tiles make it extremely simple to deliver relevant information to the Band from virtually any data source accessible through the web. Developers only have to write web tile code once to support multiple mobile platforms (iOS, Android and Windows) since the Microsoft Health app takes responsibility for doing the rest – installing the web tile to the Band, accessing web resources for content, extracting and formatting the content, and delivering that content to the associated web tile on the Band.

A web tile, fully described by a “web tile package”, contains a variety of information including tile metadata, information needed to fetch data from the web and format it for the tile, and other resources associated with creation and updates of the tile.

Then we will dive into the SDK.

We are going to look into the Microsoft Band SDK which will allow third-party application developers to harness the power of Microsoft Band. The SDK gives developers access to the sensors available on the Band, as well as the ability to create Tiles on the Band and to send notifications to these Tiles from their applications. Through the SDK, you, as an application developer, will be able to enhance and extend the experience of your application to your customers’ wrists. This opens up a whole new dimension of interaction and enables new, richer scenarios for your applications that make use of the capabilities of the Band.

Applications that work with Microsoft Band make use of the Microsoft Band SDK to communicate with the Band. The application logic runs on the host OS (iPhone, Android, Windows), and remotely controls the UI of the Band as well as receives contextual information and sensor data from the Band.

The features offered by the Microsoft Band SDK are as follows: 

Multi-platform support 

Sensor data subscriptions 

Tile creation and management 

Tile notifications 

Custom layouts 

Haptic notifications 

Band theme personalization

The SDK is also supported on a wide range of platforms. They include Windows Phone 8.1 and later, Windows 8.1 and later (Store Apps) iOS 7 and later, Android 4.2 (API 17) and later.

Channel 9 Video

In part one we did the setup. Part two we did the coding. Now we will continue some of the coding but also start looking at some configuration options.

Step 1: More Services

Lets finish up the rest of the services. We are basically mimicking what we just did for the Occasions API call for the Results and Details. If we look at the API we find the endpoint to get all drinks by occasion is /drinks/for/occasion_id. We have a route that mimics that /drinks/:filter/:id We can use this route, controller and service over and over again by changing the filter based on what we want returned. Read more “Building Cross Platform Apps with Visual Studio – Part 3”

Lets reset a bit on our project. We are starting to look at building an app that will be able to run on iOS, Android and Windows. There are a couple of ways to doing this, natively or cross platform approach. If we were to build a native app for 3 platforms we would have to code in 3 different languages and use 3 different IDE’s. (Not counting a tool like Xamarin). We are also looking at the multiple stack developer who has a lot of “web” knowledge. They know how to build web apps and their skills can translate well to this cross platform development. We will be using HTML and JavaScript to build this app. Most importantly, we will be using Visual Studio to create our cross platform app.

The app can be anything, but in this example it is a drink recipe app. Categories -> Results -> Details. That is the flow of our app. We will be using a theme from Bootstrap to make it look pretty and responsive for multiple screen sizes. AngularJS will be our JavaScript MVC Framework for the back-end. We left off with a basic “barebones” app structure that we will build upon.

Lets Begin

If you don’t know it already, mobile apps are all the rage. From social networking to pictures and videos to gaming, the app ecosystem is where you want to be. But what if you are a “one-stack” developer? What if you only know HTML/JavaScript? What if your expertise lies in Web Development? Well, they all have their challenges but over the next few articles I will try to demystify the mobile development process especially when it comes to cross platform development. The “one-stack” developer has is a bit easier. They know what the hardware will be. They know the screen size and capabilities of the device. They can reuse code over and over again and create some high quality apps. The “multiple-stack” developer has an advantage as well. They know how to code for multiple platforms. They know what may or may not be possible for each of the platforms. Lets look at the “stacks” and define them a bit.

I got an Intel Edison with a breakout kit along with a SeeedStudio IoT kit. Getting the Edison up and running was straightfoward but once that was complete the next step was “what to build?”. How abut a temperature app? Or a sound sensor? Or a blinking light. None of those thrilled me. Plus I wanted to do something totally different. I am more of an “app” guy so I started thinking about ‘apps’ that can communicate with the Edison. What can I send over to the Edison? Hmmm.

So I started where I always start for brainstorming app ideas, Programmable Web and Mashery. I scoured their listing of API’s to find one that jumped out at me. I did find one. The Absolut Vodka Drink Recipe DB. I can get drink recipes and send them to the LCD screen. This could come in handy instead of fumbling through a recipe book, or even an app. Have the LCD attached to either the shaker or the base and scroll through the steps needed to make the drink.

I am integrating the Google Places API into an iPhone app that I am building. I found an existing library that uses Google Local Search but that is deprecated. So I forked that solution and came up with Google Places Library.

As the story goes…when the application is configured to allow current location, the fun begins.

First configure your project to include the CoreLocation and the MapKit framework. I am using a single view project for this example but it can be any project really.

In the RootViewController I need to define some delegates. Since I will be embedding a UITableView and UISearchBar I need the following to be added: <UITextFieldDelegate, UITableViewDelegate, UITableViewDataSource, UISearchBarDelegate, CLLocationManagerDelegate, GooglePlacesConnectionDelegate>

UITableViewDelegate – will help populate the data on my table.

UISearchBarDelegate – will perform some interactions with the searching of places

CLLocationManagerDelegate – will get the location

GooglePlacesConnectionDelegate – will perform the main search

Once that is complete I can then add some outlets for my UI and set up some properties.

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

#import

#import

#import"GooglePlacesConnection.h"

@classGooglePlacesObject;

@interface RootViewController :UIViewController

{

IBOutlet UITableView*tableView;

IBOutlet UIButton*btnCancel;

IBOutlet UISearchBar*searchBar;

CLLocationManager*locationManager;

CLLocation*currentLocation;

NSMutableData*responseData;

NSMutableArray*locations;

NSString*searchString;

GooglePlacesConnection*googlePlacesConnection;

}

@property(nonatomic,getter=isResultsLoaded)BOOLresultsLoaded;

@property(nonatomic,retain)CLLocationManager*locationManager;

@property(nonatomic,retain)CLLocation*currentLocation;

@property(nonatomic,retain)NSURLConnection*urlConnection;

@property(nonatomic,retain)NSMutableData*responseData;

@property(nonatomic,retain)NSMutableArray*locations;

@end

Lets move on to the meat and potatoes of this app. Within the .m file I need to initialize some of my variables and get the GoogleConnection going.

The next method really starts the fun. In my case I am constructing a URL for the Google Places API. If you are not familiar with it you can find more about it here. The url takes the following parameters:

key: required – your API key

location: required – latitude/longitude around which to retrieve Place information. Location manager will help here

radius: required – distance in meters. For the initial search I have 500, for the UISearchBar I moved it out to 1000.

sensor: required – needs to be set to TRUE if came from a device with a location sensor

I am not going to dive deep into the GooglePlacesConnection class or the GooglePlacesObject. However I will say this, the GooglePlacesObject is just that. An object of the Google Place. It has an init that will take the dictionary object from the JSON results. The GooglePlacesConnection does the work of constructing of the URL and issuing the request. One thing to note, the only error checking on the Google Place request is if there are 0 results or an error with the URL or request. There are other status codes if you want to add them in if needed.

Back into the RootViewController.m, we now should have a locations NSMutableArray so we can now populate our UITableView.

The second, third and fourth method handle the interaction with the UISearchBar itself. Each calls the updateSearchString method and passes in the text from the search bar. updateSearchString performs a similar search to the location manager search, except it is passing in the search string as well. If you look in the GooglePlacesConnection method I am also expanding the search radius to 1000 from 500.

There really is not an issue (aside from image load) when viewing on Desktop browsers. However, I would like this site to be compatible with the iPad as well. Unfortunately this simple technique will not work on the iPad.

The iPad uses Mobile Safari which, by default, scales websites to fit it’s viewport. It does this to text, images and background images. It has to do with a resource limit put on the device from displaying large images. The maximum number is 1024 x 1024 x 3 which is 3,145,728 (result varies a bit depending on iPhone or iPad). However, Mobile Safari will scale your image accordingly to fit that size and your screen.

Ok. Maybe more than 8 lines of code but very little. I have been working with another agency (that will rename nameless) on a mobile web site for a client of ours. The agency provided the HTML/CSS/Images and Script for our technology team to implement. We hook up all the back end and call it a day.

The section that came into question was an ‘accordion’ style UI for a set of FAQ’s and other content. When I first loaded up their pages, everything worked fine. Upon further inspection of their code I noticed a lot of JavaScript libraries that were not needed. They included jQuery AND Prototype along with some effects and accordion scripts. (Prototype alone is almost 100kb in file size and the other scripts were 42kb. That still does not include the 70kb for jQuery) I thought to myself, this is a mobile site…why have extra scripts if not needed. To make matters even more funny, we are supporting Mobile Safari (iOS), Mobile Chrome (Android) and the BlackBerry Browser (RIM), it does not work in BlackBerry at all. Forget enabling or disabling JavaScript it just does not work. Even the elements are hidden.

So it got me thinking about the old saying, “if you want something done right you have to do it yourself”. So I did.

I removed all the libraries except for jQuery and made all of the elements visible by default. Basically if a user does not have JavaScript enabled then they can see everything.

Here is my HTML

JavaScript

1

2

3

4

5

6

7

8

9

10

&lt;div&gt;

&lt;ahref="#"&gt;Really Great Information&lt;/a&gt;

&lt;div class="accordion_content"&gt;

Content that will expand

&lt;/div&gt;

&lt;ahref="#"&gt;Really Great Information&lt;/a&gt;

&lt;div class="accordion_content"&gt;

Content that will expand again

&lt;/div&gt;

&lt;/div&gt;

Styles and other HTML can be wrapped around it. You can change the paragraph tags to div’s if needed but that is the structure you need more or less.

Now for the JavaScript.

Make sure you embed jQuery (I did from Google)

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

$('.accordion_content').hide();

//If JavaScript is not enabled, all content containers stay open, which is nice.

//Next, bind the click event to all of the targets, in this case all 'a' elements in the 'accordion_toggle' class

$('.accordion_toggle a').click(function(e){

//code to come

});

//Within the click function we need to first check if the element being clicked is set as the 'current' which means open. If it is, we need to remove the class 'current' and close the content container.

if($(this).parent().hasClass('current')){

$(this).parent()

.removeClass('current')

.next('.accordion_content').slideUp();

}else{

...

}

Then hide all open content containers:

If the element does not have the ‘current’ class then we need to first remove the ‘old’ ‘current’, close the ‘old’ ‘current’ and open and set the new ‘current’.

JavaScript

1

2

3

4

5

6

7

$(document).find('.current')

.removeClass('current')

.next('.accordion_content').slideUp();

$(this).parent()

.addClass('current')

.next('.accordion_content').slideDown();

Done.

Here is the final:

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

$(function(){

$('.accordion_content').hide();

$('.accordion_toggle a').click(function(e){

if($(this).parent().hasClass('current')){

$(this).parent()

.removeClass('current')

.next('.accordion_content').slideUp();

}else{

$(document).find('.current')

.removeClass('current')

.next('.accordion_content').slideUp();

$(this).parent()

.addClass('current')

.next('.accordion_content').slideDown();

}

e.preventDefault();

});

});

Depending on how you format the code and what you count as a ‘line’ it can be about 8 lines 🙂