It's All Just Ones and Zeros

Vault on Android - POC App

I recently decided to join the 21st century and get a smartphone.  And guess what, you can write programs on these things.  I just happen to be a programmer, so it’s app writing time!!!  Fish gotta’ swim; birds gotta’ fly.

This is just a proof-of-concept app.  It doesn’t do anything useful, but I wanted to prove that it could be done.  The app is a port of the VaultList sample in the SDK.  It lists out all the files in the Vault.  That’s all it does.

Requirements:

• Vault 2013
• An Android device - v2.1 or later

Click here for the app
Click here for the source code

---

Installation and Usage:

To get the app installed, you need to go into your phone settings an allow apps from unknown sources (non-Market locations).  Next you need to get the .apk file installed somehow.  The only way I found was to email it to my gmail account.  When I use the Gmail client on my phone, it allows me to install the app.

Running the app is pretty straightforward.  There are fields for the Vault information.  Fill it in and hit run.  You need a Wi-Fi connection to the network where Vault is running.  If you are having trouble connecting, try using the IP address of the Vault server.  You can also try opening your phone’s browser and going to http://[server]/AutodeskDM/Services/v17/DocumentService.asmx to verify that your phone can locate the Vault server.

---

Source Code:

The code is written in Java using the Eclipse IDE.  It’s similar to my other Java sample app.  For the Android app, I used a library called ksoap2 to make the web service calls to Vault.  My code is written bottom-up.  I only implemented the Vault API functions and classes that I needed.  I didn’t implement the entire DocumentService or File class, for example.  However the pattern for implementing these functions and classes is pretty obvious.

Special thanks to the DZone blog article for instructions on using ksoap2.  These developer blogs are quite helpful!

---

Future plans:

I would like to write a useful mobile app for Vault one day.  So if you have any ideas on what that app should be, post a comment.

I have no plans to develop in iPad or iPhone since it requires me to spend thousands of dollars buying a Mac.

As with all the samples on this site, the legal disclaimer applies.

Custom Objects Survey

The survey response was overwhelmingly in favor of custom objects, so I will make use of that feature where it makes sense to.  I’ll try not to go overboard... no promises.

Here are the results:

BTW, Google Docs is a great free way to create simple surveys.  Special thanks to Phil Johncock’s blog article on how to set these up.

Custom Objects or Not?

I have a dilemma, so I need you guys to fill out a quick survey for me.  On one hand I want to take advantage of the Custom Objects feature with my apps.  On the other hand, using that feature restricts the app to Vault Professional only.

For example, the 2013 version of Project Thunderdome could do some really cool things with custom objects, but any Workgroup/Collab users would be unable to use it.

Please take my 2 question survey to let me know what I should focus on.

UPDATE:  Survey is now closed.

Give Us Your Ideas

What do Abraham Lincoln, Genghis Khan and Mozart have in common?  Besides being dead, I really don’t know.  But that’s OK because it has nothing to do with this article.

This article is about the new Autodesk Vault Idea Exchange, which is where you (yes, you) get to propose Vault features.  Although we have many avenues for requesting features, such as discussion groups, the Idea Exchange is built specifically for this purpose.

Ideas can be posted, discussed and tracked.  You can also vote on ideas using the Kudos system.  Kudos is like “Like” in Facebook.  If you see something you agree with, you click on the Kudos button, and the Kudos number for that feature goes up +1.  The ideas with the most Kudos show up higher in the list. 

So go forth and give us your ideas.  API suggestions are fair game.  In fact, you are almost guaranteed a Kudos from me if you post an API related idea.  Yummy!

Lazy<> is Your Friend

The Lazy class is a nice little tool that was added in .NET 4.  Like the name implies, it helps with lazy initialization of data.  That way the data is initialized when you ask for it instead of when you class is constructed.

This is useful when programming with Vault because there are many times you need to look up server data and store it.  For example, let’s say you have a custom command that makes use of a specific property definition.  At some point you need to get the PropDef object from Vault server, but when is the best time?  You don’t want to do it during OnLogOn because it costs time to look up the PropDef, and the user may not run your command.  The best time to get the PropDef is the first time your command is run.  Then you store the object so that subsequent calls don’t have to make the same server request again.

Here is how you would look up the Author PropDef with Lazy:

' VB.NET// C# public class MyClass {     private Lazy<PropDef> m_authorPropDef;     public PropDef AuthorPropDef     { get { return m_authorPropDef.Value; } }       public MyClass()     {         m_authorPropDef = new Lazy<PropDef>(GetAuthorPropDef);     }       private PropDef GetAuthorPropDef()     {         PropDef[] defs = WebSvcMgr.PropertyService.FindPropertyDefinitionsBySystemNames(             "FILE", new string[] { "Author" });           if (defs == null || defs.Length != 1 || defs[0].Id < 0)             throw new Exception("Error looking up property definition");           return defs[0];     } }

' VB.NET Public Class [MyClass]   Private m_authorPropDef As Lazy(Of PropDef)   Public ReadOnly Property AuthorPropDef() As PropDef     Get       Return m_authorPropDef.Value     End Get   End Property     Public Sub New()     m_authorPropDef = New Lazy(Of PropDef)(AddressOf GetAuthorPropDef)   End Sub     Private Function GetAuthorPropDef() As PropDef     Dim defs As PropDef() =     WebSvcMgr.PropertyService.FindPropertyDefinitionsBySystemNames(     "FILE", New String() {"Author"})       If defs Is Nothing OrElse defs.Length <> 1 OrElse defs(0).Id < 0 Then       Throw New Exception("Error looking up property definition")     End If       Return defs(0)   End Function End Class

Web Service Compatibility

Hopefully you already know that Vault 2012 clients can access the Vault 2013 server without the need for any sort of software update.  This compatibility feature works at the web service API level.  Basically, anything that uses the Vault 2012 APIs can connect to Vault 2013.

What is compatible with Vault 2013 server:

• 2013 applications.
• 2012 CAD clients such as AutoCAD, Inventor and Civil 3D.
• Vault 2012 clients such as Vault Explorer, Autoloader and JobProcessor.
• Any standalone application that calls the 2012 web services.

What is not compatible:

• 2013 clients are not compatible with the Vault 2012 server.  The compatibility only works one way.
• Anything that is a 2012 plug-in will not be compatible with the 2013 clients.  This includes custom commands, job handlers, and event handlers.
• Anything that uses Vault 2012 API components outside the Autodesk.Connectivity.WebServices assembly may not be compatible in Vault 2013.

---

Architecture:

An API is basically an interface to an application’s functionality.  For Vault 2013, the server exposes two interfaces: the Vault 2012 set of web services and the Vault 2013 set of services.

It’s pretty straightforward.  The services are distinguished by the service URL.  Starting in 2013, there is a version component to the service URL. 
For example:
2012 URL:  http://localhost/AutodeskDM/Services/DocumentService.asmx
2013 URL:  http://localhost/AutodeskDM/Services/v17/DocumentService.asmx

If you are using Autodesk.Connectivity.WebServices.dll, it will only communicate with the web services interface for the corresponding version.  So the 2012 DLL (16.0.x.x) will communicate only with the 2012 web services, and the 2013 DLL(17.0.x.x) will communicate only with the 2013 web services.

---

Best Practices:

• Testing is still needed! 
  Don’t assume that everything works perfectly.
  
• Code to only 1 API version. 
  For example, don’t check out with the 2012 API and check in with the 2013 API.
  
• If you are building a 2013 client, use the 2013 services.
  
• Don’t hard-code data that may be version specific.  
  For example, don’t write logic around the server’s version number.
  
• Assume that your client may be used with a future Vault server.  However, Autodesk makes no guarantee that Vault 2014 will still have this compatibility feature.