03-28-2013 07:08 AM
I've been an SLX developer now for a couple of years (with a lot of C# enterprise development experience under my belt) and I have to say I am very puzzled by the current documentation situation for the Mobile product.
I have spent a LOT of time piecing together disparate documentation sources, training videos, and articles that are in many cases outdated. By Sage's own admission, documentation for the mobile product is poor. With the developer training videos (outdated in many cases), CustomerFX training videos (better, but shallow content), the ARGOS SDK wiki (targeted at 2.0), and random snippets I have stumbled upon in my research, there is no clear path to development on the mobile platform. Honestly, I feel if it weren't for Ryan Farley's toolkit work, I'd still be stumbling in the dark.
Given the obvious direction of mobile workforces in general, I sincerely hope that the leadership responsible for product management improves this situation.
Now, with that out of the way, I have been asked to assess the viability of customizing the OOTB platform for my organization. Our business needs require LOTS of customizations and I have serious concerns about the mobile apps extensibility. I'm not sure it can support our specific needs.
We have a need for many custom views that would have to be built from the ground up. These views have to consolidate data from multiple data sources that are not exposed by SDATA and display them in OOTB views. From what I've gathered, we would have to write proxies to have this data delivered in JSON anyway. Doing so takes us down the road of a full custom HTML5 solution built on the back of SubLogix and SDATA, which has the benefit of our team knowing our own solution from the bottom up without having to cobble together a bunch of possibly outdated documentation.
Where would I start in even assessing whether what we need is possible with Mobile 1.2? We don't need "this is how you set up SLX Mobile and inject a Quick Action item" information. I'm looking for more advanced customization information.
Thanks for reading and for any direction anyone can offer.
03-28-2013 08:07 AM
We've been developing in SLX Mobile for quite sometime and we have a number of projects on the go for 2.0. I can honestly say that for us the decision was a no brainer. Once the customer saw the performance and ease of use there was a real push to move as much functionality into the mobile as as possible.
As for building your own proxies I'm not sure that's really required. We have added a few Webservices for those rare times when something cannot be handled through sData but combining the normal entities with custom entities (based on views) for aggregated data and custom service operations for small complex data requests we've been able to use sData for almost all our data needs on our customizations.
Of course there's a few drawbacks we've run into so I'll share them in case this helps your decision.
1. Coding everything by hand: Basically we've had to build most of our customization by hand inside .js files. This can be tedious and time consuming. I cannot tell you how many times an extra comma has caused me grief stopping the entire application from running. JSLint and other tools can help in visual studio but there's no architect type tool yet (at least that I'm aware of) in dojo like we had with ExtJs.
2. Browser support - We're facing many customers looking at the Mobile as a "SalesLogix Lite" which means that okay they're using it on their iPhone but more and more we're seeing it being used on tablets of all makes and flavours (including Windows 8), so not supporting IE does have it's disadvantages (I'm not sure but maybe this goes away with IE 10).
3. Deployment - I've yet to dig into building my own deployment actions in the AA but this has often been a challenge since we don't like having to always remember to build and manually move .js files around to ensure that everything get's deployed properly with our bundles.
03-28-2013 08:13 AM
03-29-2013 06:20 AM
03-29-2013 06:33 AM
We've setup web services to allow us to do things that might be not be possible with sData alone. One example is we've set up a web portal for customers' clients to provide the appropriate authToken allowing contacts to login. Things like that.
We often use the sData client dll inside the WCF but on occaision we cheat and access the database directly but that's usually read-only type scenarios. If we can use sData from the client directly we do ( we build a lot of ExtJs applications built with sencha architect) we might switch to Dojo if it becomes a mature a product as ExtJS. In fact we've found that now that SalesLogix is not using the extjs core it actually helps us because we're free to use more recent versions without fear of incompatibilty with ootb UI functionality.
I'm not quite sure what you mean by custom data fields and not using sData. We have all kinds of custom data and fields in saleslogix being accessed through sData. And for aggegated information or things that don't fit into the entity model then we use service operations or custom SQL views brought into the entity framework. This will still work if you only need to deliver read only data from external sources, however if you need to push updates to sources outside sData, you may need to still pass those calls through your webservice. (We've been playing with microsoft's implementation of oData for accessing external SQL data sources and it works fantasitic (very close to sdata) and the drag and drop entity framework model really helps reduce coding time).
Personally, if I need to co-ordinate transactions into external data sources I'd opt for SQL Triggers rather than put that logic in the UI or even the middle tier (WCF) so don't have to worry about keeping various clients in sync (i.e. webclient, mobile, client, portals, integrations, etc).
Hope that helps.
04-01-2013 03:52 PM
I completely understand the frustration. Getting into mobile isn't easy and knowing what you can and can't do can be hard to understand at first. Pretty much, every things you're wanting to do is possible, but it might need some rethinking so that it fits into the mobile architrecture. As Mark mentioned there are a few different routes you could take. Adding the integration on the server so everything is returned in the SData certainly works. However, you can also customize the mobile client do to everything there as well.
I have some mobile customizations where I add the UI elements normally in mobile but then wire them up with my own code that pulls the data in from other systems. It works great and you and load in the data from the other systems asynchronously so mobile isn't slowed down by the call to the other system. You can do this to stuff in your own HTML and script sections as well. All pretty easy to do once you've done it once and figured it out, but not so easy to know where to start to do this the first time.
I actually do have a blog post written (that won't be published until later this month) that shows just how to do this. The blog post includes code that uses the Twitter API to grab the last tweet from a contact and display it on the contact detail screen. Like I said, the post is written just not published yet (I have several articles on customizing mobile that are all queued up to publish each Tuesday starting tomorrow 4/2 - it will start with basics but then builds with more advanced topics each week).
04-01-2013 03:54 PM
04-17-2013 06:27 AM
"Also, BTW, the Sublogix entities serialize easily to JSON if you wanted to go that route. With the data exposed online in someway, consuming it and displaying it in mobile is easy."
This is interesting.
We are using Sublogix now in the application that I want SlxMobile to "talk" to. This will be useful later on. We're using Mobile 2.0. I'm getting the hang of things now and I'm at the point where the heavy lifting starts.
Let me ask this - have you all just used hosted Google jQuery for your web service POSTs? We are using RESTful services for this app that I need to get data from, and getting the output to JSON is relatively easy... but I'm not sure how to integrate the JS libraries to do the actual POST/GET operations.
04-17-2013 05:29 PM
If you're using Mobile 2.0, then I'd go with just using Dojo for things instead of adding jQuery. Dojo can do everything that jQuery can do, but it is one more thing to learn
I've never tried using Dojo and jQuery in the same application, but I would think they might not play nice. Would probably be OK as long as you used the jQuery or Dojo function itself rather than the global scope $ variable (and possibly a call to jQuery.noConflict()) But, I'd not even bother and just use Dojo for everything. Is there something you wanted to do that you were thinking you'd need jQuery for? Sounds like maybe some jQuery ajax requests? You could do that with Dojo using dojo/request just the same. See http://dojotoolkit.org/documentation/tutorials/1.8/ajax/
I have two blog posts queued up that show using Dojo Ajax requests in the mobile client coming within the next few weeks that might help (I think the first of which is queued for next Tuesday).
04-18-2013 04:29 AM
"Is there something you wanted to do that you were thinking you'd need jQuery for?"
Yep, the GETs and possible POSTs to my JSON web service. My JS development background is somewhat limited so I was going to "go with what I knew" - jQuery. Thanks a lot for the link - if Dojo can do it then I'll go that route.
It turns out I may only have to do GETs at this point, which will simplify things a lot, at least starting out.