Filed under ESRI …

Dec 20 2012
Leave a comment
.NET, ArcGIS 10.1, ArcGIS Desktop, ArcObjects, ESRI

How to Create an ArcGIS Desktop Add-In with ArcObjects and .NET

This is a guest post written by Mike Miller, the author and teacher of our new Programming ArcObjects with .NET for ArcGIS 10 class.  The next session of this class will be delivered online beginning January 21st, 2013. This course will also be taught in a traditional classroom setting in Seattle, WA at the King County GIS Center from February 25th-27th.

In this first of two posts on creating ArcGIS Desktop add-ins with ArcObjects and .NET we’ll take a look at the history of programming with ESRI products as well as introduce the concept of creating add-ins with .NET.  The second post will cover the details of how you create the add-ins.

History of Programming with ESRI Products
First to put things in a historical context (from the ESRI perspective at least).  In the beginning (1982) there was Workstation Arc/INFO.  At that time very few people had desktop PC’s and what they had were expensive and limited so Arc/INFO was developed for more powerful UNIX workstations.  ESRI did eventually release a limited set of functions as PC Arc/Info which used dBase III for its database.  ArcInfo included a scripting language called AML  which was a procedural language used to extend the functionality of ArcINFO.

By 1995 Desktop PC’s had become more common, more powerful, and easier to use so ESRI released ArcView, intended to simply view data created in ArcInfo.  But as things tend to go, people wanted more capability and more power and ESRI added editing and advanced spatial analysis capability to ArcView and it became a full-featured GIS platform and they even included an object oriented programming language called Avenue

When ESRI developed Arcview they used a development toolkit called Open Interface which was a cross-platform interface that could be deployed on Microsoft Windows, Unix, and even MacIntosh.  But as computers became more powerful and more people used GIS and demanded more features ESRI ran up against some limitations in ArcView and Avenue which were being pushed far beyond their intended purposes.  So ESRI looked around to see what development platforms were available.  They chose Microsoft.

By this time Windows had essentially won the PC battle and PCs were becoming powerful enough to run large complicated software.  It seemed like the gold-standard.  So they completely re-wrote ArcINFO from the ground up using a Microsoft technology called COM.  At the time it was the largest implementation of COM ever, even larger than Microsoft Office, so it was a huge undertaking.

They called the new software ArcGIS and because they used COM they were able to expose all of its functionality to developers without actually releasing the source code.  ArcGIS itself was actually written using ArcObjects so that anything you could possibly do in ArcGIS you could do programmatically with ArcObjects.  From a developers standpoint  this was fantastic.  But it required learning a whole new language and more in the way of basic programming knowledge.  It was not as accessible to the end user as AML or Avenue.

There were two ways to access ArcObjects, Visual Basic for Applications was included with ArcGIS and allowed you to write ArcObjects programs from within  ArcGIS.  Or you could create COM components outside of ArcGIS using a COM compliant language like Visual Basic or Visual C++.  This allowed greater flexibility but also was more complicated and required Visual Studio.  But things progressed and Microsoft developed .NET technology which was incompatible with VBA and they began phasing out VBA.

ESRI saw the writing on the wall and looked around at what was available again and saw Python.  Python was cross-platform which allowed it to be used on non-windows machines, and it was independent of Microsoft.  It had a lot of flexibility and ESRI decided to include it to allow basic scripting of geoprocessing tasks in 9.0. They still had ArcObjects but they offered Python and the Geoprocessing framework as a more accessible way to extend ArcGIS.

In ArcGIS 10 ESRI phased out VBA completely and included Python in the core ArcGIS products.  They also exposed more functionality with ArcPy, ArcPy.mapping, ArcPy.sa, ArcPy.ga, ArcPy.da module.  This seems to be the wave of the future.  This is only my opinion but I think ESRI has a bit of buyers remorse after going whole hog with Microsoft in 2000 and are looking for options to go back to a more cross-platform environment down the road and Python may give them that opportunity.

BUT

ArcGIS is still written with ArcObjects.  ArcObjects is not going away anytime soon.  It was Microsoft’s decision to deprecate VBA not ESRI’s.  There is a huge amount of code out there written using ArcObjects and nobody wants to re-write it for Python, even if they could

EVERYTHING in ArcGIS is exposed to ArcObjects.  There are no limitation.

Python has quite a few limitations of its own.  If you are a software developer the Visual Studio development environment is far superior to Python but more complicated and more expensive.

So ESRI had a dilemma.  How do they prepare for the future and provide a simple, free, scripting environment for end-users but still allow the flexibility that ArcObjects provides and allow users to continue using their existing VBA code base.

Introducing Add-Ins
What they came up with is the Add-In framework.  Writing ArcObjects code using COM is more complicated than most GIS Users want to deal with.  It requires components to be registered through the windows system registry and that is opening a large bag of worms that most GIS users would prefer not to deal with.  Deployment requires installation software that handles the work of registration but it is another learning curve that keeps GIS developers from focusing on GIS.

Add-Ins are much simpler.  The basic framework occurs in declarative XML which is relatively easy to read.  There is no need to register components or deal with complicated installation programs.  Add-Ins are a single file that you can give to people via e-mail or over through the web.  Clicking on the add-in file automatically installs it on the system and its functionality is there when you open ArcGIS.  It can even be put on a network share so that an entire corporation can have access to the add-in without a need to install on individual machines.

So, if you are new to programming in general or at least to programming in a GIS environment, which development environment should you choose?  As you can gather, there are a lot of options out there.

Python has a lot of things going for it, especially if you are primarily a GIS user and simply want to automate some processes.  If the current ArcPy modules will do what you need, or if you are patient enough to wait until ESRI exposes more functionality (which they are doing all the time) then you might want to invest in learning Python.

Or if you want to be able to run geoprocessing scripts in a UNIX environment you are stuck with Python because ArcObjects is based on COM and will only work on windows machines.

If you are just starting out as a GIS developer it might be a good idea to start with Python and look into ArcObjects if you find it doesn’t meet your needs.  Because Python seems to be the wave of the future and ESRI is putting a lot of effort into making it useful for extending GIS functionality.

Advantages of Using ArcObjects
ArcObjects also has a lot of things going for it.  If you are already familiar with ArcObjects you might find Python extremely frustrating because the development environment is extremely limited and the functionality is also limited.  Especially if you need a more complex user interface than provided through ArcToolbox.  In particular if you already have an existing codebase that you’ve been working on for years you probably don’t want to re-write it all.

Again, ArcGIS is written using ArcObjects.  It would theoretically be possible to completely rewrite ArcGIS using ArcObjects so there are really no limitations on what you can do with it.

In particular, any type of user interface that you can imagine can be developed with ArcObjects.  Anything that you see other windows programs doing you can likely re-create in Visual Studio, while Python is limited to the ArcToolbox interface.

I’ve mentioned the development environment a few times.  What I mean by that is Visual Studio which has a visual interface for creating user interfaces using drag and drop methods.  Also the code editor is amazing with AutoComplete and Intellisense and context specific help.  It makes it much more efficient to write error-free code.  And if you fail to write error-free code on your first attempt the debugging environment is also amazing.  Python has none of these features and if you spend a lot of time programming it is probably well worth your time and money to purchase Visual Studio and use it for extending GIS

There are other things that you simply can’t do in Python.  These include feature class extensions, server object extensions, and creating an entire ArcGIS extension.  Finally, performance is also an issue.  ArcObjects is compiled code while Python is interpereted.  As such it is generally much faster and so if performance is critical, you should consider ArcObjects.

The Add-In Framework
The add-in framework relies on a declarative XML document rather than COM registration to let ArcGIS know what components and assemblies are part of the Extension.

XML is a tag based language similar to HTML.  A major difference is that the tags can be defined to represent anything rather than conforming to a specified standard.  This allows individuals to create their own schemas for what tags to use and how they should be implemented.  Thus the name Extendable Markup Language

ESRI devised a schema for ArcGIS add-ins that includes things like the name of the add-in, the author, the version number, and the target.  The version number is checked automatically and if it is a newer version it will be installed automatically.  The target could be ArcMap, ArcCatalog, ArcGlobe, etc.  Then it lists the items that are in the add-in, such as buttons, tools, combo boxes.  It also lists item groups that are menus and toolboxes that list the individual items on them.

In the next post in this series we’ll show you how to create a simple add-in for ArcGIS Desktop using ArcObjects and .NET.

 

Oct 25 2012
Leave a comment
ArcGIS Desktop, ArcGIS Server, ESRI, GeoSpatial Training Services, HTML5, JavaScript, OpenLayers, PostGIS, Python

Upcoming Class Schedule

Schedule of Internet Based, Instructor Guided Classes

Programming ArcObjects with .NET for ArcGIS 10.1
November 26th – December 21st

ArcGIS Server Bootcamp for New Developers
November 5th – December 14th

Design and Build GIS Web Sites Like a Pro
November 5th – November 21st

Python ArcGIS Programming Bootcamp
January 7th – February 8th

Building Custom ArcGIS Server Applications with JavaScript
January 14th – February 22nd

Building Mobile ArcGIS Server Applications
January 14th – February 22nd

ArcGIS Server Bootcamp
January 7th – February 15th

Open Source GIS Bootcamp
OpenLayers + GeoServer + PostGIS
January 2013

HTML5 and CSS3 for GIS Web Developers
November 5th – 16th

Schedule of Traditional Instructor Led Courses

ArcGIS Server Bootcamp for New Developers
Atlanta – November 5th-9th

ArcGIS Desktop 3: Analysis and  Workflows
Atlanta – November 8th-9th

GIS Programming 101 for ArcGIS 10
November 29th-30th
Austin, TX

Python ArcGIS Programming Bootcamp
January 28th-30th
Seattle, WA

Programming ArcObjects with .NET for ArcGIS 10.1
February 25th-26th
Seattle, WA

May 30 2012
Leave a comment
ArcGIS Desktop, Geoprocessing, GeoSpatial Training Services, Python

15 Python and ArcGIS Posts (and 1 Free Lecture) from GeoChalkboard

Through the years we’ve posted a number of informative, how-to style articles related to using Python with ArcGIS Desktop to automate your geoprocessing tasks.  To make it easier for you to find articles of interest I’ve compiled a list of these posts.

Want to learn more about using Python with ArcGIS 10 and ArcGIS 10.1?  We have a number of instructor led and self paced training opportunities.

Python ArcGIS Programming Bootcamp
Next Session: July 9th – August 10th

GIS Programming 101 for ArcGIS 10

GIS Programming 201 for ArcGIS 10

ArcGIS Programming with Python Bundle

 

May 06 2012
Leave a comment
ArcGIS 10.1, ESRI, Geoprocessing, GeoSpatial Training Services, Python

Creating Add-Ins with Python at ArcGIS 10.1

Add-ins provide an easy way to distribute user interface customizations to end users.  No installation programs are necessary.  A single compressed file with a file extension of .esriaddin is copied to a well-known folder and ArcGIS Desktop handles the rest.  To simplify development even further an Add-In Wizard has been provided by ESRI.  You can download the wizard from the ESRI website.

The Python Add-In wizard, which you can download at the link provided above, is a great resource for creating the necessary files for an add-in.  It generates the required files for the add-ins from a visual interface.  After downloading and unzipping the file from the ESRI website you’ll want to double click addin_assistant.exe in the addin_assistant/bin directory  to run the wizard.

The add-in file structure is really quite simple.  Two folders and a set of files comprise the add-in structure.  The images folder contains any icons or other image files used by your add-in.  The Install folder contains the Python script that handles the business logic of the add-in.  This is the file you’ll work with extensively to code the add-in. It performs whatever business logic needs to be performed by the buttons, tools, menu items, etc.  The config.xml file defines the user interface and any static properties such as the name, author, version, etc.  The makeaddin.py file can be double clicked to create the .esriaddin file which wraps everything into a compressed file with an .esriaddin extension.  This .esriaddin file is what will be distributed to end users.

There are a number of add-in types that can be created.  The simplest type of add-ins are buttons and tools.  Buttons simply execute business logic when clicked.  Tools are similar to buttons but require interaction with the map before the business logic is executed.  Combo boxes provide a list of choices for the user to select from.  There are also a number of container objects including menus, toolbars, and tool palettes.  Menus act as a container for buttons or other menus.  Toolbars are a container for buttons, tools, combo boxes, tool palettes, and menus.  They are the most versatile of the add-in container types.  Finally, tool palettes act as a container for tools.  Tool palettes need to be added to a toolbar before the tools will be exposed.  Finally, application extensions are the most complex add-in type.  This type of add in coordinates activities between other components and is responsible for listening for and responding to various events such as the addition or removal of a layer from a data frame.

Creating Add-Ins
Creating an add-in project is the first step in the creation of a new add-in.  To create a project open the ArcGIS Python Add-In Wizard and select a working directory and then enter the various project settings.  Finally, click the Save button, but don’t close the wizard.  You still need to follow specific steps for creating the particular add-in you’d like to deploy.

The creation of an add-in follows a well defined process which is described on this slide.  You must first create a container for the add-in and this will be either a toolbar or a menu.  Next, create the button, tool, or other add-in you want to add to the container.  In this case we’ll just assume it’s a button.  Next, you need to edit the Python script associated with the button.  You’ll also want to test the button to make sure it works as expected.  Finally, you can share the add-in with others.

The first step is to create a container for your add-in.  This is easily accomplished through the Python Add-In Wizard.  Go to the Add-In Contents tab and right click the Toolbars Item.  Select New Toolbar.

After the container Toolbar has been created you can then create the button or other type of add-in.  In this case we’ll assume you’re creating a button.  Right click the new Toolbar and select New Button.  Then, fill in the button details which will be saved to the config.xml file.  Click Save to save this information to config.xml.

Add-ins have a Python script that they are attached to.  This file, by default, will be named AddIns_addin.py and can be found in the install directory of your working project folder.  Inside the script you’ll want to locate the ‘onClick’ event.  You’ll need to alter this function as needed to handle what happens when the button is clicked.

You’ll want to always test add-ins before distributing them to your end users.  To test you first need to install the add-in.  In the working folder for your add-in run the makeaddin.py script by double clicking it.

This copies all files and folders to a compressed add-in folder in a working directory with the file format: <working folder name>.esriaddin.  Double click this .esriaddin file to launch the ESRI ArcGIS Add-In Installation Utility which will install your add-in.  You can then go into ArcGIS Desktop and test your add in. The custom toolbar or menu may already be visible and ready to test. If it is not visible, go to the Customize menu and click Add-in Manager. The Add-In Manager dialog box lists the installed add-ins that are targeting the current application. Add-in information, such as name, description, and image, entered as project settings should be displayed.

If the add-in is listed in the manager, click the Customize button to open the Customize dialog box. To add a toolbar to the application, click the Toolbars tab and choose the toolbar you created. To add a menu to the application, click the Commands tab and scroll down the list of categories to [ MENUS ] and find your custom menu. Drag the menu onto an existing menu or toolbar. If the add-in is an extension, be sure it is enabled. Open the Extensions dialog box and check it to enable it.

Want to learn more about using Python with ArcGIS 10 and ArcGIS 10.1?  We have a number of instructor led and self paced training opportunities.

Python ArcGIS Programming Bootcamp
Next Session: July 9th – August 10th

GIS Programming 101 for ArcGIS 10

GIS Programming 201 for ArcGIS 10

ArcGIS Programming with Python Bundle

 

 

 

 

 

 

 

 

 

 

Mar 11 2012
Leave a comment
ESRI, Python

GIS Programming 201 for ArcGIS 10 Coming Soon (ArcGIS 10.1 Materials Included)

On May 15th, 2012 our new self-paced, GIS Programming 201 for ArcGIS 10: Mastering Python course will be released.  For a limited time you can pre-purchase this course at the discounted rate of $109.00.  The regular price for this course will be $129 when released on May 15th.

All new and updated for ArcGIS Desktop 10.1.  This course builds on the introductory topics you learned in our GIS Programming 101 for ArcGIS 10 course. You will learn more advanced topics in this course including how to select, insert, update, and delete data from tables and feature classes using the new Arcpy Data Access Module (ArcGIS 10.1), develop add-ins for ArcGIS Desktop (ArcGIS 10.1), administer ArcSDE geodatabases (ArcGIS 10.1), create graphs, use custom and remote ArcGIS Server toolboxes, mosaic datasets and publish image services, learn raster analysis with the Arcpy Spatial Analyst module, and more.

Course participants will be led through a series of 8 modules described below.

Bundle this course with our GIS Programming 101 for ArcGIS 10 and save!

Intended Audience
This course is intended to be taken after our GIS Programming 101 for ArcGIS 10 course.

Modules
Module 1: The Arcpy Data Access Module
Module 2: Developing Add-Ins for ArcGIS Desktop with Python
Module 3: Using and Administering ArcSDE Geodatabaeses with Python
Module 4: Creating Graphs with ArcPy
Module 5: Using Custom and Remote Toolboxes
Module 6: Advanced Topics: Mapping Input Fields to Output Fields, MultiValue Inputs, FeatuerSet and RecordSet
Module 7: Creating Mosaic Datasets and Publishing Image Services
Module 8: Beginning Raster Analysis with the Arcpy Spatial Analyst Module

Mar 05 2012
Leave a comment
ArcGIS Server, Dojo, ESRI, GeoSpatial Training Services, JavaScript

Anatomy of a Hybrid Mobile GIS Application

There are essentially three types of mobile application development including native, web, and hybrid solutions.  What most people associate with mobile applications or apps are native applications.  These are applications developed specifically for a particular mobile operating system platform.  For example, most people associate apps in the Apple Store as native applications.  As we’ll see this isn’t always the case though.  Web applications developed for the mobile platform are run in the browser on the mobile device (Safari for example).  Finally, Hybrid applications are a combination of the two, and as you’ll see they may well be the preferred method of mobile application development for most applications moving forward.  In this post we’ll examine each of these application development types.

Native Mobile Applications
Native applications are developed specifically for the mobile device that it will be run on.  For example, applications that you download from the Apple Store are often native applications for the iPhone or iPad.  Different languages are used to develop these native applications.  Applications developed for the iOS are created with Objective C, C, or C++.  Android applications are developed with the Java programming language.  These applications will run more efficiently than web or hybrid applications because they are compiled specifically for the operating system where they will run.  Natively developed applications can also use all the phone’s features including the camera, geolocation, the users’ address book, and more.  You don’t have access to all these functions when developing web mobile applications.

As I mentioned, native application development must use the language specific to the platform for which you’ll develop the application.  The most common mobile development environments and their programming languages are illustrated below.

Native Application Development Process
The source code for natively developed application is written in the specific language for the platform being used.  This course code is then compiled into an executable file.  This is similar to traditional desktop application development.  Any resources that need to be bundled with the application are then combined with the binary output from the compiler to produce a distribution package.  Resources are typically things like images and icons that are used in your application.  The distributable package is then ready for inclusion in the app store specific to your environment.  App stores vary in their requirements for applications, but all include some sort of approval process which can be time consuming.

Image from Worklight.com

Native applications have full access to the operating system API on which they are developed.  Your source code makes calls into the OS specific API to access the various services available on the platform.  This will vary by platform, but all natively developed applications have full access to the functions provided.  This includes functions such as data storage, location, camera, speaker, microphone, and others.

Image from Worklight.com

Native applications have a number of advantages.  As I mentioned these applications have full access to all features of the mobile device so they are able to offer the full range of functionality.  Native applications also do not have to be connected to the web to be used.  They can be used in offline mode.  In contrast, web applications always need access to the internet.  This is changing though as you’ll see later.  Finally, native applications get good visibility with consumers because they are distributed through the phone manufacturer’s app store.

There are also a number of disadvantages associated with natively developed applications.  Because they are developed for a specific platform (operating system and device) the number of users that can be reached is restricted.  For example, if you develop an application for Android devices, Apple users will not be able to access the application unless you specifically write the application for the iOS.  This can lead to a lot of duplicate work.  Third party approval can also be barrier.  You have to wait for approval for the application to be published to the app store so you have limited control over the timing of the distribution.  All of this means you’re duplicating work on different patterns.  This can be time consuming and costly.

Mobile Web Application Development Process
Web applications, in contract with native applications, are run inside the phone’s browser.  For example, on the iOS platform this would be the Safari web browser.  These applications are developed with HTML, CSS, and JavaScript.  Unlike native applications, web applications work across all devices which ensures cross-platform compatibility and doesn’t require that you produce individual applications for each platform.  Negatives of mobile applications developed for the web include limited access to mobile device features.  Also, these applications can’t be deployed to the phone’s marketplace.

The web application development process is quite different from native applications.  Applications are run through the browser on the mobile device.  In this case there is no need for an app store since the application runs through the browser instead.  One of the drawbacks of using this type of development process is that you don’t have access to the full array of operating system functions provided by the mobile device.  In fact, this set of functions is quite limited on many devices.

Image from Worklight.com

There are a number of advantages to using a mobile web application development process.  The primary advantage is that these applications are compatible across all platforms and devices so your application has greater reach without the need to re-write the application for each platform you intend to run on.  Since they run in a web browser, these applications can also be developed using traditional web technologies such as HTML, CSS, and JavaScript which makes the technical barriers to entry low since most web developers already have these skills.  Companies can also make use of mobile search to allow their consumers to find the application.  Since the application will not be part of the app store for a device no third party approval is required before release giving you more control over your product.  The site can then be updated in real-time and changed without requiring sign-off by a mobile provider.

There are some disadvantages to using a mobile web application development process.  The primary disadvantage is that you can’t make use of many of the phone’s built in features such as the camera or the address book.  They also can’t be deployed to the phone’s marketplace which limits the visibility of the application in some ways.

Hybrid Application Development Process
Hybrid applications combine the best attributes of native and web based mobile application development.  This application development process enables cross platform development with HTML, JavaScript, and CSS while still having access to the phone’s features.  In this model, selected portions of the application are written using web technologies and a bridge such as PhoneGap (http://phonegap.com) is used to access features of the device operating system and package the application for inclusion in the app store for the platform.  This option allows companies to reap all the benefits of native apps while ensuring the  longevity associated with well-established web technologies.  The Facebook app is an example of a hybrid application.  It is downloaded from the app store and has all the features of a native app, but also requires updates from the web to function.

The application development process for hybrid applications is somewhat more complex than the other models because it incorporates features of both.  Native source code is written and compiled into an executable program as described earlier in the module.  In addition, a web based component written with HTML, JavaScript, and CSS is also written.  It accesses content provided by a web server and is included with other resources into a distributable package for the app store.  This hybrid approach is quickly becoming the preferred route for many mobile application development efforts.

The hybrid application development process is really the best of both worlds.  You have full access to the native operating system functions while also being able to take advantage of existing web development skills such as HTML, JavaScript, and CSS.  This type of approach does require the use of a bridge technology such as PhoneGap.

Image from Worklight.com

PhoneGap has two primary tasks.  First, it enables you to take an existing code base and deploy to multiple mobile platforms.  This is quite important as it removes the need to re-develop an application for each platform that you intend to use.  PhoneGap also provides access to the operating system functionality provided by the mobile device.

Image from Worklight.com

Mobile JavaScript Frameworks
As part of the mobile application development process you are going to want to use a JavaScript framework of some type for user interface development.  There are a number of frameworks including Dojo, jQuery, Sencha, and others.  These libraries emulate the native widgets found in mobile applications.

HTML5
HTML5 is in widespread use in mobile web application development.  The top supported features of HTML5 on mobile devices include audio and video, geolocation, offline web application support, web storage, CSS3 selectors, and 2D animations.  For an extensive look at mobile compatibility with HTML5 features please visit the link provided on this slide.

ArcGIS Server JavaScript API
Your traditional web mapping applications developed with the ArcGIS Server API for JavaScript can easily be ported to a mobile platform.  Starting at version 2.0 (current version is 2.7) of the ArcGIS API for JavaScript, a compact build can be used to limit the footprint of the API resulting in quicker downloads.

This smaller footprint is a great choice for mobile applications including the iPhone and iPad.  There are two primary differences between the standard and compact builds of the API.  First, the compact build only loads objects that are needed for your application.  For example, if you don’t need a Calendar widget then it’s not loaded.  The second difference is that the compact build only loads 32 code modules instead of the 80 modules loaded with the standard Dojo build.  If you need to use a code module that is not downloaded as part of the compact build then you can use dojo.require to load the specific module you use.  You’ll also notice that various user interface components have been altered to make them easier to use on a mobile platform.

Choices, Choices
So, at some point you will need to make a decision on what type of application development process you intend to use for your application.  Your choice may vary depending upon the needs of the application.  Considerations include time, budget, and resources available to develop each solution.  In general, native applications cost more and take more time to get to market, but the user experience is often better in terms of functionality and performance.  Web applications, while they tend to cost less and can be developed more quickly don’t have quite the user experience as they don’t run as fast nor do they have access to the full capabilities of the platform.  Hybrid applications provide an excellent alternative by combining the best features of both platforms.

Skills Development
There are a lot of skills that you need to acquire to develop hybrid mobile applications.  If you’re already a web developer your HTML, CSS, and JavaScript skills may already be well developed.  In addition to these traditional web application development skills you’ll also want to learn a mobile JavaScript framework such as Dojo mobile or jQuery mobile.  PhoneGap is also a necessary skillset you’ll want to develop as it provides the bridge between traditional web development and native mobile development.  You’ll also need to have a good understanding of the ArcGIS Server API for JavaScript so that you can take advantage of all the GIS functionality provided by this platform which can be used on a mobile device.  Finally, you’ll want to have a good understanding of mobile device specific functionality.

Building Mobile ArcGIS Server Applications
It’s obviously a lot to learn, but our new Building Mobile ArcGIS Server Applications course is designed to get you up to speed with developing hybrid mobile GIS applications.  By the end of this class you will be well on your web to developing some great mobile GIS applications.  The first session begins April 16th, 2012.

Jan 23 2012
Leave a comment
ArcGIS Server, Dojo, ESRI, GeoSpatial Training Services, JavaScript

New Class: Building Mobile ArcGIS Server Applications

The first session of our Building Mobile ArcGIS Server Applications course will be offered beginning April 16th and runs through May 18th.

There are a tremendous number of mobile application development platforms including iPhone, iPad ,Android devices, Windows 7 devices, Blackberry, and others.  Developing applications for each of these platforms can be a time consuming, frustrating process.  It is not uncommon to develop the exact same application multiple times; once for each supported platform. What a waste of resources!

Using a combination of the ArcGIS Server API for JavaScript, HTML5, CSS3, and PhoneGap you can resolve this problem!  This combination of tools allows you to build your ArcGIS Server applications once and deploy to all mobile platforms that you intend to support.

This course will teach you how to build high performance, attractive mobile GIS applications using the lightweight, browser based ArcGIS Server JavaScript API using JavaScript, HTML5, CSS3, and PhoneGap.

Course Modules
* Mastering the ArcGIS Server API for JavaScript
* HTML5 and CSS3
* DojoX Mobile
* PhoneGap
* Capstone Project

Tagged ,
Oct 24 2011
Leave a comment
AGIS Server API for Flex, ArcGIS Server, ESRI, GeoSpatial Training Services, JavaScript

Learn to Program ArcGIS Server with JavaScript or Flex

The final web based, instructor guided sessions for 2011 of our Mastering the ArcGIS Server JavaScript API and Programming the ArcGIS Server API for Flex classes begin next Monday, October 31st.  We still have a few seats available for each class.

Get free access to the first module in our Programming the ArcGIS Server API for Flex here.

Price for each course is $567 through Oct. 26th.  Price increases to $715 after this date.

Aug 05 2011
Leave a comment
ArcObjects, GeoSpatial Training Services

Free Course – Programming ArcObjects with VBA

Although VBA is still available if needed at ArcGIS 10 it will not be supported at release 10.1.  You can read more about this here and here.  We’ve decided to go ahead and retire our Programming ArcObjects with VBA course and make it available free of charge as a self-paced course.  I know there are still a lot of you working on ArcGIS Desktop 9.3 so hopefully this will help those of you still working with that release.

This course is broken into two sections: Introduction to VBA for ArcMap and Introduction to ArcObjects.  They are meant to be taken in sequence.  Exercises for the course come from the book Getting to Know ArcObjects which you’ll need to purchase if you intend to complete the exercises.  However, the lectures provided above are free for all to use.

For more information on other courses please visit our website.

 

Jul 27 2011
1 Comment
.NET, AGIS Server API for Flex, ArcGIS Server, ArcGIS Server for Silverlight, ESRI, GeoSpatial Training Services, JavaScript, Open Source GIS, OpenLayers, PostGIS, Python

GIS Salary Survey Results

We’re keeping the survey open through July 31st.  If you haven’t already participated in the survey please take a few moments to do so and forward this to your colleagues.

To date we have had 731 respondents.  Here are some of the highlights:

  • 40% of respondents list their job titles as either GIS Analyst or GIS Technician.  16% are GIS Managers/Coordinators/Directors, and 6% GIS Developers/Programmers.
  • 40% of respondents have 10 years of experience or greater.
  • 43% have a Master’s degree or higher.  Should You Get a Master’s Degree in GIS?
  • 70% of respondents are male.  I suppose this is better than it was 10 years ago, but we really need to attract more women to the field.
  • 41% of you are between the ages of 30-39.  24%  are between the ages of 40-49.  Less than 2% are above the age of 60.
  • Salaries appear to be widely dispersed with 29% between $50,000-$70,000/year.  I was surprised to see almost 13% below $20,000/year.
  • ESRI is far and away the most popular platform with 93% of respondents indicating this as one of their primary platforms.  This question allows more than one platform to be selected.  Open Source GIS software came in second at 14%.  I suspect this will grow quite a bit in the coming years.
  • Primary programming languages in use include .NET (55%), Python (50%) , JavaScript (27%), Java (20%), and Flex (17%).  You can learn more about Python, JavaScript, and Flex through our training classes.

You can get all the results here.

← Older posts