3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

The mobile dev world is buzzing with the Axway news that was revealed earlier today. To summarize the announcement:

  • The Axway Appcelerator Indie development tier is now free.
  • Hyperloop is now included with the Indie plan and is now free for all developers.
  • Appcelerator Arrow Builder is now called Axway API Builder and is also included in the (now free) Indie plan.

Hyperloop is Axway’s next-generation compiler that gives Titanium mobile developers full access to the native iOS, Android, and Windows APIs, all from within JavaScript.

Axway API Builder is a tool for creating, managing, and orchestrating APIs. It allows developers to expose and control the flow of data from multiple sources using many builtin data connectors. API Builder is also extensible and allows devs to use Node.JS to create their own connectors, flows, endpoints, etc.

Quite simply this means that every mobile developer is only a few JavaScript lines of code away from any native API. Axway is opening the door for mobile developers to have free access the Axway Appcelerator platform tools including Titanium, Hyperloop, API Builder and more!
Demand for training and developers with experience with both Hyperloop and Axway API Builder will undoubtedly increase as a result of these recent changes. Axway has strategically partnered with Shockoe to develop new training courses for both Hyperloop and Axway API Builder. Shockoe’s development experience with both of these products also enables us to continue giving our clients a feature rich experience, from apps to APIs.

Interested in what it would take to kick off your project?

Our experience and core services include strategy & transformation, user experience & design, mobile application development, and API management.

Digital transformation through an attorney’s eyes

Digital transformation through an attorney’s eyes

Like many of my colleagues at Shockoe, I began writing computer code in a high school classroom.  However, in my case, the school was particularly advanced for its time in offering such a course, and our “computer” was a keyboard, dot-matrix printer, and a modem connection to the University of Virginia, where the actual computer occupied an entire floor of a large building.  And while most of those colleagues went on a path that brought them relatively quickly to Shockoe, I spent two decades working as an attorney in New York, Seoul, and Virginia.

Now in my third year of software development I have felt particularly happy to be at Shockoe because I believe it addresses needs that I often saw during my time working as an attorney, needs that I am certain are shared by many industries.

In my experience, the following was typical of the manner in which law firms implement technology.  First, the decisions are made by senior partners who, being busy with the representation of clients, have little time to keep up-to-date with what is available or most desirable in technology.  This leads either to an “if it ain’t broke, don’t fix it” mentality, or an attempt to take care of the problem in one fell swoop with a package solution that may or may not fit comfortably with the way they have set up their practice.  In the latter case, the acquired technology may go unused, or used only to the extent required by the firm.  For example, if a time-tracking application is difficult to use, an attorney may keep track of his time on post-it notes as she always did before, then have her secretary type it all into the application at the end of the week.

In either case, what then happens is that employees begin finding their own solutions. Each attorney and his or her assistants devise their own system, piecing together hardware and applications as they see fit.  Depending on their level of technological sophistication, they may, or may not, arrive at a solution that works well for them.  However, this approach drastically reduces the potential for collaboration, and creates a host of potential problems, as the less technologically-adept might adopt solutions that introduce security vulnerabilities or other problems.

Although so often noted as to sound trite, an average employee today with a typical mobile device is comparable to an employee with superpowers two or three decades ago. To make the most of those powers, however, requires sophisticated solutions.  This includes, of course, a focus on the possible pitfalls of any new technology. A device that allows employees to watch training videos at convenient times may also allow them to spend the working day watching Netflix. Large collections of data become valuable, and thus must be protected, not only from hackers in foreign locales, but from disgruntled or former employees.  Yet while minimizing risk demands much attention, it is just as important to make certain that new technology is used to its full potential. Making one’s workforce five times more efficient is simply not good enough in a competitive business environment if the competition makes their workforce eight times more efficient.  

This is what excites me about working at Shockoe, being able to use my skills to allow our clients to make the greatest possible use of the technology available to them. Apps created now increase employee productivity, streamline task performance and ensure employees have real-time data access they need for day to day exchange opposed to the opposite stagnant mentality. If this sounds familiar to you, check out our work for Financial Services Mobile Technology and contact us for any innovative ideas to help your team tackle your digital transformation with a great mobile strategy.

Dear New Client . . .

Dear New Client . . .

Dear New Client

We are so glad you have trusted Shockoe to help accomplish your business goals.  We understand that for this particular project, you need to design and build a new workplace productivity mobile app for your employees.  Here are some highlights of what you can expect throughout the course of this project.

Project Set up and Kickoff:  The kickoff meeting will provide an opportunity for all team members to meet, review the project scope, timeline and processes, and discuss any anticipated challenges.  Topics covered will include milestones and key dates, responsibilities, recurring meetings, status reporting, how we will work together, and contact information.

Discovery:  Once we’re out of the gate, we will interview your stakeholders and subject matter experts to deepen our understanding of your business model and goals for this project.  A Shockoe user experience strategist will lead this effort and may suggest activities such as market research, competitor analysis, identification of user personas, or a heuristic evaluation of your current application.  Along the way, we will document your requirements and create user flows and user stories.  Typically, a user interface designer is involved in this phase as well so the transition to design is seamless.

Design:  Once we have outlined what your new application needs to do, our design team gets to work.  These folks are the masterminds of creating a top-notch experience for your target audience.  They start by creating mockups (wireframes) that show the key elements on each screen and how a user progresses from screen to screen.  These mockups are easily transformable into clickable prototypes if desired for review by your team or to conduct usability testing with a sample audience.  Beyond that, we bring your screens to life with a style guide and high-fidelity designs.  Together these paint the picture of how the application will look and feel and will include actual colors, fonts, and images.

An agile-like process:  Typically, at some point between the transition from Discovery to Design, we will start to employ an agile approach to the project.  The goal is to share our work early and often so that you have visibility along the way.  Together we can determine the right amount of upfront user experience planning that’s needed before we move into iterative sprints.  Sprints are typically two week intervals where we identify an area of the app on which to focus, we wireframe it, apply the design, and build it.  The sprint culminates with a demo at the end where we share our work and gather your feedback.  Everyone looks forward to demo time!

Development:  The scope of the project determines how many sprints are needed.  No matter how many two-week intervals are involved, the process is the same and all members of the team know what to expect.  Each sprint includes sprint planning, development of the relevant user stories, a day or two of testing and issue resolution, and finally, the sprint demo at the end.

Testing and launch:  After the last development sprint ends, we spend a couple of weeks regression testing, which is thorough testing of the entire app to ensure that all functionality is working as expected and that there are no display issues across supported devices.  Any issues identified are resolved and then the app is turned over to you to perform user acceptance testing.  Fortunately, you will have had access to the app at each sprint demo when the QA version of the app is uploaded to Shockoe’s server for download.  This testing at the end of the project is an opportunity to execute all test cases and confirm the final product is ready.  Beyond that it’s just a matter of planning for submission to the app stores.  Shockoe can either help you through that process or submit the app on your behalf.

We are with you throughout the life of the project and let you know what to expect at each step of the way.  We find that by the end of a project, our collective team has bonded in a way unlike no other.  We are working together to produce something that will make people’s lives better in some way.  And that’s a great feeling.  Thank you for letting us be a part of it.

Let’s get started . . .

The Shockoe Team

So you have an app idea – now what?

So you have an app idea – now what?

So you have an awesome idea for an app. There’s just a burning hole in your front screen every time you unlock your phone. Your idea is keeping you awake and with many sleepless nights, you just know this is it! Your app is revolutionary and will change the world, and really, you are just sooo ready to make a gazillion million dollars. So now what?

As a marketing/sales coordinator at Shockoe, I receive a lot of phone calls stating just that. I’m not kidding. Some obscure, some genius and some just plain mind blowing. As a one of the fastest growing companies in Virginia our deep passion lies in making beautiful and useful apps with great technology – nothing gets us more excited than a chance to help you bring your idea to life. So I’m here today writing a little guide, if you will, to help you navigate in this craze driven mobile world and give you a couple of pointers to consider before diving head deep into the commitment of making your app. So here goes nothing.

First – I’d like to bring it to your attention that making an app is a full on business. That’s right, one that requires planning, skills for development, design, support of the product, marketing, money and the list goes on. So you might say, of course, that’s pretty obvious. I’m willing and ready to put this much into my app idea because I know it’s going to do well. Well here’s what to consider next.

Is your app going to promote an existing business or is it a completely separate entity you would like to make money from? If it’s an existing business app idea serving as a compliment to your service, do your research. Search through app store or google play – see which ones failed and which ones worked before and play around with existing apps.

And now, the juicy part – the price. Do you price it “free” or do you charge users for downloads? How much of a budget did you set aside towards the actual creation of your app? Is it going to be an Iphone app, Android or both? Do you want us to make your app completely from scratch or do you want to put in the time to write a basic code and have us help you make it pretty and functional? Now, what about getting your app out there? Are you going to promote it and market it out yourself? What is your time line in completing the app and how fast do you want it to hit the market? And once it’s out, how will your app updates and bug fixes along with any other tweaks will be handled?

As you can see, the list goes on and on. At Shockoe, we are proud to say that we can help you with the entire process. From creating a strategy and defining how this app will help your business and what you can do to take advantage of your mobile strategy. To then of course, carrying out this idea and knocking out the user experience and design portion of it to make sure your baby is effective, productive and adds value. Then doing the development and integration portion of it (and trust me I’ve seen our developers typing away their codes – it really does looks like an intimidating different language to a non-techie like myself). To then, the customer success management portion which is critical to your mobile app’s success! We want to make sure your mobile solution never loses value to your users and we ensure you receive the best application support, maintenance & monitoring services you deserve.

Anyways, the team is pretty awesome and as stated before: we will get it done because mobile apps are our number one passion. So to do it right, making an app is a full business but we are certainly here to help you every step of the way!

So what are you waiting for? Go ahead and contact us now and let’s get your awesome app idea out into the world!

Node Summit 2016

Node Summit 2016

Last week I had the pleasure of attending Node Summit 2016 in San Francisco. I am eager to share some of the new cool technologies and concepts I learned about while I was there.

NodeSchool is a tool for learning node and javascript concepts. If you have node and npm installed, starting a lesson is as easy as installing a new node package; these lessons range from utilizing node tools, to the nuts and bolts of creating and publishing a node package.

The one hardware workshop at the conference proved to be perfect office hackathon fodder. Particle.io is a platform for interacting with internet of things devices, and using node and their Photon microcontroller we were able to program a row of lights to act as a scoreboard for a game of tic-tac-toe. As someone who deals strictly with software, it was a welcome diversion to play around with breadboards and resistors for a few hours.

One of the most insightful and fun presentations I attended during my time at Node Summit was on security. This talk featured a lot of great examples of trying to hack into or disrupt a locally hosted web application. Of course, the main thrust wasn’t to teach people how to hack–though I can’t say I didn’t learn a thing or two–but to show how out-of-date node modules can bring security vulnerabilities to your codebase. The presentation concluded with a stern warning that actual hacking was illegal and an insight into a current company for those in need of a fix:”bugcrowd” a platform that lets companies pay bounties to hackers to break into their systems so that they can close any security gaps.

The main buzzword at the conference was micro-services. Every sponsor from NASA to Netflix gave talks on how they have transformed their entire systems over to use this architecture concept.

Micro-services are not specific to node, but node’s flexibility means that it lends itself well to the concept. The micro-service pattern refers to breaking out all of the functionality of your product into independent pieces, instead of housing them within a single unit–known as a “monolith”. This way, when you make changes to your app, you don’t have to redeploy your entire codebase. Instead you’re deploying just the parts of the app that were affected by changes. This works especially well in node because you to pull in only the modules you need for each individual micro-service, and there are tons of node modules out there designed with communication between micro-services in mind.

Looking back at the conference as a whole, I was inundated with the vastness of node itself. Every year for the past four years the numbers of new node users has doubled, and there are 300+ new modules published every day. This has inspired me to try them all out and bring cool new technologies back to Shockoe.

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.

Page 1 of 212