Why We’re Rebranding: a Letter from Our CEO

Why We’re Rebranding: a Letter from Our CEO

Hello from the world of Shockoe!

As some of you might have noticed over the last few days, Shockoe is sporting a brand new logo. It’s an exciting era for our company — our steady growth has brought new clients, new teammates, and pushed us into our larger digs in Scott’s Addition. It’s a great time for Shockoe!

You’ll see it’s not just our logo that is changing. We’ve changed our website, our social media, our messaging, and our focus to better reflect the way we help our clients succeed. What we’re saying should not sound unfamiliar to those who have worked with us. Our mission is only a refined version of what we have always known well about ourselves: we make quality apps that make users lives measurably better. In short, we’re Shockoe: we’re mobile by design.

So what’s changed?
Actually, not much. We’re bigger and better — our consulting-focused approach to developing apps remains, but is now a thriving team of developers, strategist, and designers. We have 35+ talented individuals and a growing client portfolio that we can be proud of. It’s truly our growth that has helped us realize our focus and expand the breadth of expertise that Shockoe truly represents.

From grocery store apps in the southeast to managing herd health in Canada — it’s felt like we do a bit of almost everything. That said, we have seen a few trends surface, and began to recognize we are particularly fantastic in a few different areas of mobile development. It’s what we’re calling our “pillars,” and what is ultimately the driving force behind the utility apps we create. What are these pillars? I’m glad you asked!

If you want to learn more about what each one means, I encourage you to visit our new website where you can read more on each pillar and read supporting case studies. Additionally, our latest three blog posts take a leap into the various pillars as we aim to push thought leadership that helps companies bring mobile apps to more processes, internal operations, and customer loyalty strategies. I encourage you to hop in and check things out.

We’re incredibly proud of the work that we do at Shockoe and thankful for the employees, the partnerships, and clients that have accompanied us in our growth. We owe this rebrand to all of you.

As always, if you have any questions, please don’t hesitate to reach out! Until then, keep an eye on Shockoe as we continue our growth and continue our campaign to be the best damn mobile shop around.

Sincerely,

edwin huertas signature

 

Edwin Huertas, CEO

Kotlin: Three Reasons To Start Using It Today

Kotlin: Three Reasons To Start Using It Today

With the announcement at Google I/O 2017 that the Kotlin programming language will be officially supported as a first class citizen for the Android framework, there’s been a lot of talk around what Kotlin is and how it compares to Java. This post highlights the reasons why our development team at Shockoe feels that Kotlin is the wave of the future and why Android developers should start adopting it.

What is Kotlin?

Kotlin is a statically typed programming language that runs on the Java Virtual Machine (JVM). It’s a multi paradigm language that contains elements of object-oriented programming that you’d see in languages like Java and elements of functional programming like what you’d find in JavaScript.

Why should you start using Kotlin?

Here are our top three reasons why you should jump in:

#1 Easily integrated into your mobile stack

Kotlin code is compiled into the same bytecode that your regular Java programs are and uses the Java Virtual Machine (JVM) to execute that code.
This means that Kotlin still has access to all the same libraries and frameworks available to you in the Java world with the addition of those from the Kotlin standard library. This also allows Kotlin and Java code to run concurrently with one another. Java classes calling methods in Kotlin classes or libraries and vice versa. This can even be done in the same file. Take this example from a library that handles unit conversion:

fun celsiusToFahrenheit(value: Double): Int = Math.round(value * 1.8 + 32).toInt()

Here we have a function that takes a Double parameter and returns an Int. However, we want to use the java.lang.Math class to round as this feature doesn’t exist in Kotlin. So we round to the nearest place and call a method from the Kotlin Double class to convert the result into an Int.

This duality of execution allows developers to easily convert their existing Android projects from Java to Kotlin or to simply add new features written in Kotlin, without converting previously written code.

Additionally, Kotlin has an option to compile into JavaScript which is compatible with the standard JavaScript specifications like Asynchronous Module Definition (AMD), CommonJS, and Universal Model Definition (UMD). This allows developers to share code written in Kotlin to other environments like Node.js or even to cross platform environments like to Appcelerator’s Titanium framework.

#2 Multi-paradigm language

A lot of the developers from Shockoe come from multiple different backgrounds. Some started with Java and transitioned into writing JavaScript while others started with JavaScript and have since learned about other languages.

Kotlin adds a lot of functional features to the object-oriented nature of Java. I realize that Java 8/9 adds similar features but this post is specific to the Android platform.

These features coupled with improved/sugar syntax lead to a much more easily read codebase. I won’t go over all the features but some of the most prominent ones are higher order functions, null safety, better typing with type inference, and much less boilerplate code.

These features, in particular, allow a developer to write much cleaner code and a lot less of it. Here’s an example of some Java code to perform and common action – filtering a list:

 ArrayList getAllEvenValues(int[] values) {
    ArrayList filtered = new ArrayList<>();
    for (int i : values) {
       if (i % 2 == 0) {
          filtered.add(i);
       }
    }
    return filtered;
 }

This isn’t too terribly much but it can quickly spiral out of control as you start adding more complexity. The Kotlin equivalent would look like:

fun getAllEvenValues(values: List): List = list.filter { it % 2 == 0 }

Yep, that’s it. There are many more operators that can be appended to the end of that, for instance if you wanted to map the results to strings and return the string list you just make one minor change.

fun getAllEvenValues(values: List): List = list.filter { it % 2 == 0 }.map { it.toString() }

#3 Official Support From Google

No brainer here, right? However, the announcement from Google I/O 2017 is a huge deal for the language. In addition to the benefits of Kotlin over Java such as those detailed above, Kotlin will now have full support in Android Studio and within the Android ecosystem. JetBrains and Google are working together to continue to support the language into the foreseeable future.

Kotlin is by no means meant to replace Java. However, it will allow for better apps to be written using a much more modern and architected language that keeps developers in mind.

Conclusion

Now is a great time to jump into Kotlin and to start writing your Android apps with it. It will lead to better productivity for your mobile team, as they’ll be writing less code – which will be more readable and therefore easier to maintain.

Additionally, if you’re a multi-platform development team, the cross compilation into JavaScript is a great addition as you can easily create tools that work within frameworks for both languages.

Then there’s also the similarities between Kotlin and Swift as is highlighted here. This helps  bridge the gap between iOS and Android development teams.

Additional Resources

Official Kotlin Documentation

Sample Kotlin App

Kotlin Android (Layout) Extensions

Anko – Library with many Kotlin helper tools for Android

Kovenant – Promises for Kotlin

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Titanium to Native Android: These aren’t the frameworks you’re looking for

Titanium to Native Android: These aren’t the frameworks you’re looking for

A little about the developer

Having been working with the Titanium mobile application framework for the better part of the last year, I have developed an appreciation for what it does and what it tries to do. Creating a true cross-platform framework that tries to do almost everything that each native framework can do and unifying those into a singular codebase is definitely a challenge, one that Appcelerator has done well. After working on several projects with the framework, I feel that my programming skills and my understanding of the mobile world have drastically improved.

That being said, I wanted to start working more in the native world to get a better understanding of what Titanium was doing behind the scenes. This led me to start exploring the native frameworks for iOS and Android. I have focused on Android as I have a decent Java background. I’ve always believed that the best way to learn something new is to just dive in and figure stuff out as you go. Thus, I decided to recreate the very first application that I worked on after starting at Shockoe. The new application was dubbed Doorman as that was ultimately it’s basic purpose. It’s meant to act as a virtual doorman for people walking into the office. After getting the API setup, I jumped into writing the code and learning more about Android.

My Impressions of Android

My initial impressions of native Android development were very good. While it did have a learning curve, once I started to get a better understanding of activities, intents, services, etc it was a breeze to work with. It did miss some of the libraries that Alloy had access to like Moment, Underscore, and Backbone but I learned to work around them. Probably the most noticeable difference in the Android world coming from Titanium was the sheer amount of developer support found on the web and documentation. In addition to the amount of documentation put out by Google, the number of Stack Overflow posts with developers having similar problems really helped me with detailed explanations and examples from responses. It was indeed a breath of fresh air for a new developer just starting to get their feet wet. Even working with third party libraries was simple as they were optimized to work within the Android environment and I could use them directly rather than having to create a separate module to link the two together. Appcelerator did have a lot of detailed documentation that I heavily relied on, especially when working on the already existing codebases that used components and proxies with which I wasn’t very familiar. However, there were times when I ran into an issue that I couldn’t resolve with the documentation. The fewer number of developers post on internet made it more difficult to find a resolution if my fellow Shockoe developers couldn’t help me.

Setting up Jenkins

Once I was comfortable enough with the state of the application and API that I felt a test build was necessary I moved over to work with Jenkins, our build environment. Initially, I was a bit nervous about getting the build setup. I hadn’t yet built the application through the command line but instead was using Android Studio. As it turned out, it was a very simple process to get the builds created and uploaded after some research into Gradle, a fantastic build tool for Android applications. With just two shell commands I was able to build the application and get the .apk file to send to AppTracker, our in-house distribution service. I was amazed how easy it was to get setup. However, it didn’t take long for me to realize that the app was showing errors when trying to install on a device. Turns out that I wasn’t signing my apps before uploading them. Oops. Again, with the help of the large number of Android developers on Stack Overflow, I was able to determine that I needed to adjust my Gradle scripts a bit. I just needed to link a .keystore file to the Gradle build command then bam, signed .apk files to upload to AppTracker. The app was then ready to install on device.

Overview

Overall, I really enjoyed the experience working in the native world. I learned a lot about the what is going on behind the scenes when developing Titanium apps. I believe that this understanding will help me to become a better developer going into the future. While I know that Titanium won’t be going away anytime soon as it is a great tool for creating quality applications and a relatively small time frame from not having to create and maintain two separate codebases, I would love to continue learning more about the native world.

Metalling with Titanium: Building my first Alloy application

Metalling with Titanium: Building my first Alloy application

 

Event listeners. Callback functions. Asynchronous programming? These words were foreign to me when I first started working at Shockoe LLC the first week of October 2015. But somehow, I needed to use these things to create a mobile application in the next two months.

I wasn’t completely new to programming. I had recently taking Java programming courses and was learning other languages like C++ and C# by watching online tutorials. Before I started working at Shockoe, I was told to learn JavaScript as that was predominately what I would be using to create Titanium Alloy applications. Going through the tutorial on CodeAcademy taught me little about the language. It seemed to be mostly a tutorial on what programming was. But I figured that since I had the gist of programming, I wouldn’t have much of an issue as anything could be solved with a simple Google query.

Showing up to work on the first day taught me that that wasn’t the case. Edwin, the CEO at Shockoe, assigned me to work on Fighting Mongooses, a name with which I’m now beginning to understand the logic behind.

The concept behind the app sounded pretty simple but integrating various devices, a server, a database, and mobile OS’s turned out to be far more complex than I had anticipated.

The first week or two was spent just trying to figure out what was actually happening in this partially built application.  I slowly started to figure out what the different pieces of code were doing to understand the logic. I used what was already available to piece together a rudimentary working application to fulfill the initial requirements and to prove I could fit in at Shockoe.

From there, I slowly expanded the capabilities of the application and learned more about Appcelerator, Titanium, and JavaScript along the way. After a month and a half of working on Fighting Mongoose, it has taken on a bit of my own personality. It is no longer another developer’s application that I was given to complete and that is a great feeling.

There is still a lot that I need to learn to get near the level of the other developers here, but I have had some great guidance and help while working on the Fighting Mongooses project.

I still have much that I wish to accomplish with the application and feel more comfortable and confident each day with what I’m doing.

I recently found an old version of the app on a device I used for testing about a month ago and it’s amazing to see for myself the progress that I have made since.

I look forward to see the kind of progress I can make in the next month on onward here at Shockoe.

 

 

Can you QA test this? …

Can you QA test this? …

… is the first question an agile developer should ask of them self.

Agile development is a continuous, flexible feedback loop driven by collaboration, adaptive planning, dynamic development, early delivery, and constant improvement. This continuous integration approach to development has a dark side – the potential to continuously integrate defects.

Successful agile development requires testing as a strategic component of each project: Agile development requires agile testing.  As code architects and engineers, developers are best qualified to identify areas of potential risks. Developers are critical in creating and implementing an efficient, effective testing strategy.

Developers are the first line of defense in detecting and eradicating defects. Applying best practices during coding reduces the number of introduced errors. Catching and correcting defects before they are introduced into a distributed app is far more productive than pinpointing and fixing a multitude of problems days or hours before delivery deadlines.

Testing on developer environment simulators is the first means of testing an app, however, it does not expose all defects. Simulators do not represent the actual device or user events encountered in real device use. Actual devices are the only means to test real user experience – have you ever seen an end-user run their app on a simulator?

After passing initial testing on the development simulator, the app is ready to be built on the continuous integration (CI) environment. Builds deployed to devices from the developer environment may not exhibit defects resulting from different CI configurations. While CI performs testing on various levels, developers should verify and validate CI builds prior to passing apps to third persons for manual testing or automated QA frameworks outside the CI.

Developers using cross-platform solutions, such as those used by Shockoe, can often decrease development time, testing complexity, and costs. Today’s multitude of device chipsets, memory, display, sensors, OS versions, OEM and carrier modifications, and third party software dependencies can make “test often” overwhelming, expensive, and dramatically reduces the time a developer can spend developing.  Shockoe employs tools to streamline the seemingly endless possibilities of testing required to assure stable products and heightened user experience.

Automated testing on actual devices can be performed in-house and by cloud-based services. These automated testing frameworks increase the number of tests that can be run in a time frame, reduce the time it takes to expose defects, and shortens overall time to market. Automated testing frameworks do not make errors. Developers should witness the first few automated passes, as they are most familiar with the product’s performance expectations and nuances.

Human testing comes with long time cycles, high costs, and is prone to errors. While automated testing solves these human detriments, they do not accurately test for design issues and overall user interaction experience. Whether testing in development simulators, performing manual tests on CI builds, or watching the first few passes of an automated test, only a human can test for human experience factors.

Developers produce the code that is the app. They are integral to the testing processes at all levels of production. Before a developer asks, “Can someone QA test this?” they should employ development best practices, testing techniques, and tools to ensure those “QA-ing” find few, if any defects.

Appcelerator Titanium iOS Debugging with XCode

Appcelerator Titanium iOS Debugging with XCode

Earlier this week, I was debugging and I was reminded of the sheer power of the XCode developer tools, even in the context of a not-quite-native application like a titanium application.

The Problem

Andrew was working on an application that will load in a large number of images and PDFs from a remote server and display them to the user, in-app. However, when we got to the point that we would be displaying a certain one of our images, we saw this in the Titanium console:

[ERROR] invalid image type. expected TiBlob, String, TiFile, was: TiBlob -[TiUIImageView setImage_:](TiUIImageView.m:687)

Sorry, what? It seems like something odd is happening at a native level, and Titanium is getting too confused to return a sensible error message. Well, guess it’s time to open a support ticket with Appcelerator and wait for them to figure out what the issue could be, right?

Wrong. One of my favorite things about Appcelerator Titanium is its open-source nature. What we can do from here, is open up the native project generated by Titanium and debug it with the normal native debugging tools. When you build a Titanium application for iOS, a (pretty much) normal XCode project is generated from your project, compiled, and run on whatever test device you have selected. In situations like this, we can take that project and manually re-build it in XCode for debugging purposes.

Opening your project in XCode

To open your project in XCode, first run

ti build -p ios --build-only

in your project’s directory. This will ensure you have a native project generated for your Titanium project. From here, all you need to do is open XCode, and open up the XCode project in the build/iphone folder.

Path to a Titanium project's compiled XCode Project

Setting Native Breakpoints

Now that we’ve got the project in XCode, we need to set up a native breakpoint so that we can see what the issue is with the Objective-C code that Titanium is executing on our behalf. Fortunately, the message that Titanium printed out gave us a selector name:

-[TiUIImageView setImage_:]

. Let’s go ahead and set up a symbolic breakpoint for that selector:

Add a breakpoint in XCode by clicking the second icon from the right in the side bar, and then clicking the plus in the bottom right

Add the symbol from the error as the symbol name

Enter the XCode debugger

Now that we’ve got our breakpoints set up, we can run the project in XCode, and execution will stop when our breakpoint is hit in the Titanium SDK code.

The debugger will automatically pause execution when you hit a breakpoint.

Let’s go ahead and step over a few commands and see if we can figure out exactly what’s going wrong.

Step Over

Huh, it looks like we’re having some issue turning our Titanium file into a UIImage that we can apply to the native UIImageView. Let’s use the variable inspector to figure out exactly why we’re failing to convert this into an iOS image.

XCode variable inspection

Well, one look at the MIME type is enough to see exactly what’s wrong. Our file isn’t an image! Even though this didn’t tell us exactly where the issue was, it was enough to direct our debugging (we eventually figured out that we were accidentally saving a PDF file as an image – oops!). Issues like this are why I’m very quick to reach for XCode when I see a native iOS issue – it makes it much easier to figure out what parts of your code might be incorrect when you can easily trace through Appcelerator’s code!

API Description Language for the Enterprise

API Description Language for the Enterprise

REST, now estimated to be used by 90% of new APIs, is great for groups within a corporation that can engineer their API as quick as lean startups. However, REST doesn’t fully meet the needs for enterprise businesses. With their slow-moving review and approval processes, internal politics, and sometimes a large user base, enterprise businesses require an API that can be simple to manage, quick design process and also be able to use standardization across potentially hundreds of other APIs across multiple line of business.

It’s been more than a couple years now since we started to look for API Description Languages that can fit small to large companies. Anything that can help the communication between Back-End and Front-End developers to be fast, easy and standardized, it’s been something that we always strive for. Swagger and RAML, both are API Description Languages that meets those needs.

It has been suggested that RAML may be the perfect solution for designing the next generation of enterprise level APIs, but as you might know enterprises still using SOAP based APIs and, of course, WSDLs are still the king.

With Swagger or RAML, at the end of the day, you are trying to describe an API by writing JSON, and since it’s JSON, there are many tools out there that will help you generate these documents via nice editors (GUIs).

 

Rapid Titanium WebView debugging with Chrome Developer Tools

Rapid Titanium WebView debugging with Chrome Developer Tools

Any Web Developer worth their salt is already familiar with the awesome Chrome Developer Tools package that ships with Google’s Chrome Browser.  What you might not know is that Android 4.4 introduced a powerful new native debugging tool for native Android/HTML5 hybrid apps that allows you to attach Chrome Developer Tools to a Web View running on a physical android device.  As part of our continuing mission to help you tame the Mobile Monster, we’ve taken the liberty of wrapping the code to enable this functionality in a Titanium-ready mobile module.  To make use of this new functionality in Titanium, you will need :

  • A laptop with the Google Chrome Browser
  • A phone running Android 4.4+ (and a charging cable)
  • An app built with Titanium SDK 3.4.1.GA +

Getting Started

First, download the pre-built module below.

[ No module needed on Android 4.4.x+ ] (update)

To make use of the module within your Titanium project, you just need to un-zip the module into your modules folder, and add it to your modules tag in your tiapp.xml.  We recommend only including this module for the development deploy type, since this is purely a debug tool.



com.shockoe.debug.webview

Now, just build your app to an Android 4.4+ device, and you will be able to attach chrome developer tools to any web view within your app.

Attaching Chrome Developer Tools

Once you have your app on your test device, and have your test device connected to your development laptop, open Google Chrome and type chrome://inspect into the address bar.  This should open you up in the devices tab.

 

The Chrome developer tools device perspective

Then just click inspect.  A normal Chrome developer tools window will open, allowing you to inspect your element as normal.  In addition, you can click the new icon in the top-right of the screen to get a live preview of your WebView directly within the inspector window.

The Chrome Developer Tools inspector with on-device preview

 

And that’s it. You now have a full-featured Chrome Developer Tools window attached to your Titanium app’s WebViews, allowing you to use all of the same web development tools that you are familiar with from normal HTML/CSS/JavaScript apps to develop Titanium/Mobile Web hybrid apps.

Enabling Push Notifications Part 3 of 3

Enabling Push Notifications Part 3 of 3

Android Code Setup

Android is set up the same way with just a few minor differences.  On Android, we use the ti.cloudpush module and ti.cloud for Push Notifications.  After registering with the server, the function should return a device token.  Save this device token in-app properties.

Example: Ti.App.Properties.setString(‘deviceToken’, e.deviceToken);

 However, make sure you set the application properties on the callback and not inside the common JS library.  These lib files can sometimes act strangely when it comes to saving app properties.

//require the notifications common js lib file
var notifications = require('notifications');
//check for a device token
var deviceToken = Ti.App.Properties.getString('deviceToken');

//check to see if deviceToken exists
if(deviceToken === '') {
	//get the devices token
	deviceToken = notifications.getToken();
	//set the deviceToken app property
	Ti.App.Properties.setString('deviceToken', deviceToken);
}

In the index js file we set up the device to look for a token and if there is not one to register the user for Push Notifications.

//require ti.cloudpush module
var CloudPush = require('ti.cloudpush');
//require ti.cloud module
var Cloud = require('ti.cloud');

//get device token
exports.getToken = function() {
  // Initialize the module
  CloudPush.retrieveDeviceToken({
      success: deviceTokenSuccess,
      error: deviceTokenError
  });
  // Enable push notifications for this device
  function deviceTokenSuccess(e) {
      CloudPush.enabled = true;
      return e.deviceToken;
  }
  function deviceTokenError(e) {
      alert('Failed to register for push notifications! ' + e.error);
  }
  // Process incoming push notifications
  CloudPush.addEventListener('callback', function (evt) {
      alert(evt.payload);
  });
};

The device token that is generated will allow the application to receive notifications.  You will be able to register the device with ‘Channels’.   The server can push information to certain Channels.  Say you want sports news.  Then a Channel called ‘sports_updates’ could be created.  Channels are not done server side.  Creation is done on the user side.  There is not a way to manually add a channel on the ACS Dashboard.  Once a user subscribes to a channel for the first time then it is created.

Subscribing a device token to a channel is a function in the common JS library you created for Push Notifications.  In this function, we pass two variables. One being the channel and the other being the device token that was generated earlier.  Each one is needed for the subscription.  Now the module ti.cloud will be required for this project as well.  The first module, ti.cloudpush, is just for registering a device token, and ti.cloud does the rest.  So we add ti.cloud to the notifications lib file.

//subscribe to a specific channel
exports.subscribe = function(channel, token) {
    Cloud.PushNotifications.subscribeToken({
        device_token: token,
        channel: channel
    }, function (e) {
        if (e.success) {
            alert('Subscribed');
        } else {
            alert('Error:\n' + ((e.error && e.message) || JSON.stringify(e)));
        }
    });
};

Subscribing a device token to a channel is a function in the common JS library you created for Push Notifications.  In this function, we pass two variables. One is the channel and the other being the device token that was generated earlier.  Each one is needed for the subscription.

You will also need to allow the user to unsubscribe from Channel based Pushed Notifications, which can be done using the unsubscribe function.

//unsubsribe from a specific channel
exports.unsubscribe = function(channel, token) {
    Cloud.PushNotifications.unsubscribeToken({
        device_token: token,
        channel: channel,
    }, function (e) {
        if (e.success) {
            alert('Unsubscribed');
        } else {
            alert('Error:\n' + ((e.error && e.message) || JSON.stringify(e)));
        }
    });
};

//device token
var deviceToken = Ti.App.Properties.getString('deviceToken');
//require notificiations lib file
var notifications = require('notifications');
//create view to house label and buttons
var container = Ti.UI.createView({
	width           : Ti.UI.FILL,
	height          : Ti.UI.FILL,
	top             : 30,
	layout          : 'vertical',
	backgroundColor : '#FFFFFF'
});
//create label for title
var channelLabel = Ti.UI.createLabel({
	width     : Ti.UI.FILL,
	height    : Ti.UI.SIZE,
	text      : 'Select a Channel',
	textAlign : 'center'
});
//create sports channel button
var sportsButton = Ti.UI.createButton({
	width     : Ti.UI.FILL,
	height    : Ti.UI.SIZE,
	top       : 10,
	title     : 'Sports'
});
//sports button event listener
sportsButton.addEventListener('click', function(e){
	if(deviceToken !== '') {
		notifications.subscribe('sports_updates', deviceToken);
	} else {
		alert('Error, device not registered for Push Notifications');
	}
});
//add elements together
container.add(channelLabel);
container.add(sportsButton);
$.win.add(container);

Now we need to create a sample page to test this all out with.  It will have a view, label, and button.  Clicking this button will subscribe the user to sports updates from the ACS server.

 This will create a basic view with a label and button on top of the window.  It will say ‘Sports’ and upon click will call the register function from the notifications lib file.

notifications.js

exports.userLogin = function() {
    // Log in to ACS
    Cloud.Users.login({
        login: 'push_notifications',
        password: 'pushy'
    }, function (e) {
        if (e.success) {
            alert('Login successful');
        } else {
            alert('Error:\n' +
                ((e.error && e.message) || JSON.stringify(e)));
        }
    });
};

You can also have users set up on the ACS server and log them in and subscribe to channels.  However, the user account must exist.  Generally, one user is created for the public, such as the ‘push_notifications’ user we see in the code.   This is perfect for just a basic app with notifications.  If you want user sessions and give the ability for people to create their own accounts you will have to look into Titanium.Cloud.Users on the documentation.

Sending Push Notifications using the Dashboard (http://dashboard.appcelerator.com)

This will cover three different ways for notifications to be sent.

Sending to Specific Channel/Users
Sending to All Channels
Setting up Recurring Notifications

 

Go to the Dashboard, then Cloud, then Push Notifications.  You will see a button that says ‘Send Push Notification’, click on it.

Sending to Specific Channel/Users

  • Channel – Which channel to send the notification to

    • Choose ‘Specific Channel’

  • Choose ‘Specific Channel’

  • Users – You can choose to enter a username if you have created any to notify just users who subscribe to that channel.

  • Alert – The message body you want the user to see

  • Send When – The time you would like to send the notification

    • Choose ‘Send Now’

  • Title – The title of the notification

Let’s say we notify the ‘sports’ channel, then we need to choose ‘Specific Channel’ under the Channel.  Then under ‘Channel Name’ you would put ‘sports’.  The ACS server is Case Sensitive, so stick with lowercase or camel case.  For the ‘Alert’ section just come up with something such as ‘Richmond, Virginia to get a Major NFL Team’.  Under ‘Send When’ choose ‘Send Now’.  Then for ‘Title’ enter ‘WZYB Sports’ or something like that.

 

Click ‘Save Changes’ which will send the notification to the subscriber devices.

Sending to All Channels

  • Channel – Which channel to send the notification to

    • Choose ‘All Channels’

  • Alert – The message body you want the user to see

  • Send When – The time you would like to send the notification

    • Choose ‘Send Now’

  • Title – The title of the notification

Click ‘Save Changes’ which will send the notification to the subscriber devices.

Setting up Recurring Notifications

  • Channel – Which channel to send the notification to

    • Choose ‘All Channels’ or ‘Specific Channel’

  • Alert – The message body you want the user to see

  • Send When – The time you would like to send the notification

    • Choose ‘Recurring’

    • Enter the Start Date, End Date, Cycle and Time of Day

  • Title – The title of the notification

Click ‘Save Changes’ which will send the notification to the subscriber devices.

That concludes this tutorial on Push Notifications.  Please feel free to leave a comment and let us know if this worked for you.