Alternate thread title: “This is why you shouldn’t use Servoy Mobile”. It’s a closed system that relies on us to wait for Servoy to make changes. To the functionality, to the widgets in the editor, to even what client-side library is being used.
At the pace that technology in the mobile space is currently evolving, Servoy’s approach is not sustainable and cuts out experimentation. A few of us have argued for much more “pluggable” approach: viewtopic.php?f=16&t=19471&start=15#p105151 with the core component being a client-side js library that encapsulates foundset-esque functionality.
The goal being to have a connector that you can use to backend Servoy to whatever client-side thing out there: Sencha Touch, KendoUI, Enyo, etc. The argument against is that you can already do this with REST but my argument is that there is a whole layer that could be wrapped around REST that would be specific to Servoy.
For example, a mythical Angularjs example. HTML:
<!DOCTYPE html>
<html ng-app>
<head>
<title>Angular with Servoy</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="SERVOY.connection.udp" content="Employee"/>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.4/angular.min.js"></script>
<script src="test.js"></script>
<link rel="stylesheet" href="bootstrap.min.css">
</head>
<body ng-controller="personCtrl">
<div ng-repeat="employee in employees">
<form class="form-horizontal">
<fieldset>
<legend>{{employee.firstname}} {{employee.lastname}}</legend>
<div class="control-group">
<label class="control-label" for="inputLastName">Last Name</label>
<div class="controls">
<input ng-model="employee.lastname" type="text" readonly="readonly"/>
</div>
</div>
<div class="control-group">
<label class="control-label" for="inputFirstName">First Name</label>
<div class="controls">
<input ng-model="employee.firstname" type="text" readonly="readonly"/>
</div>
</div>
<div class="control-group">
<label class="control-label" for="inputAge">Age</label>
<div class="controls">
<input ng-model="employee.age" type="text" readonly="readonly"/>
</div>
</div>
</fieldset>
</form>
</div>
<script type="text/javascript" src="../ROOT/DataAccess/Loader.js"></script>
</body>
</html>
This line tells the Servoyjs what database connection and table to load client-side:
<meta name="SERVOY.connection.udp" content="Employee"/>
This line is the Servoyjs call:
<script type="text/javascript" src="../ROOT/DataAccess/Loader.js"></script>
And this is the “test.js” used to bridge data from Servoy to Angular:
var personCtrl = function ($scope) {
var scope = $scope;
SERVOY.onAfterInit = function () {
SERVOY.employee.foundset.loadAllRecords().toArray('lastname, firstname, age', {
top : 40,
onSuccess: function (evt) {
scope.$apply( function() {
scope.employees = evt.result;
})
}
})
}
}
Hides all the REST stuff into something an average Servoy developer could get their heads around.
Basically, I think the current mobile approach is the result of trying to be too “Servoy-ish” about the whole thing with severe lock-in as a result. When really we would all be so much further ahead right now if Servoy was pursuing a “putting a Servoy facade” approach on all the forward-thinking javascript stuff going out there.
Nobody cares about Servoy Mobile – too many better ways out there to skin that cat (and more being released every month). But if there were a Servoy data connector, the Servoy Mobile forum would be filled with examples of top Servoy devs doing cool things with mobile clients backed by Servoy.
My $.02