Can I implement a rules engine like Jess into Phonegap? - ios

I am soon beginning to develop a mobile application for my Final Year project in computer science. I am keeping my options open in regards what to use to create the application. I heard Phonegap is quite a handy API but can I still implement things such as JESS rules?

It's called Apache Cordova now, Phonegap is a hosted build system (personally not a big fan of it, maybe it has improved now... anyway).
Using Cordova, you write the cross-platform application bits using JS, not Java.
So if you want to write something similar to JESS in JS this is possible and will give you a cross platform app.
I can imagine that calculations on rules might be computationally intensive so maybe not that suited for JS. In that case note that you can write plugins for Cordova using other languages and call those from Javascript. But you will need to implement the plugin for iOS/Android/... separately using their respective toolkits.
Instead of using Cordova you can decide on Android/Java only. This should be easier and faster, albeit not cross platform. In that case, keep in mind that Dalvik (the android JVM) is not the same as stock JVM. This means that not every Java program can be run an Android without modifications.
HTH.

Related

Is there any lightweight Angular alternative?

I come from Vue.js to Dart world, and Angular is look for me very heavy and ugly. Is there anything more lightweight and compact for client side?
If you want something minimal, you might like MDL and over_react. Even just using the SDK's low-level DOM API gets you a long way (compared to vanilla JS).
FWIW, AngularDart is getting less and less heavy each month, and on bigger projects it doesn't seem uglier than Vue.js to me -- but I understand everyone has their own preference.
You can try the "Regoch SPA" http://www.regoch.org/single-page-app
The Regoch SPA is framework for developing single page, web applications. Created in modern Javascript with recent version of ECMAScript it's extraordinary simple and intuitive. Learn it in a few hours and build app like Angular, Vue or React.
Features
no slow compilation as in Angular, Vue or React (no such compilation
at all)
lightweight application - small app file size (~50kB only)
JS files builded with the gulp and browserify (very fast)
use CommonJS and write the code just like you are doing that in
NodeJS by using require()
no typescript, no heavy compiling, no bullshit
Model-View-Controller (MVC), intuitive app structure easy to learn
and to use
due to its small size you can build very fast and reactive mobile
apps
steep learning curve (you'll reach high programming skills rapidly
fast)

Flex Mobile Project vs. Action script Mobile Project

I am new to development and would like to develop an android application. I have previously built an application with Adobe Flash Builder 4.6 with Flex Mobile Project. I just recently noticed in 4.7 there is an option for Action Script Mobile Project.
Can someone please explain to me the difference between the two and the pros and cons to utilizing either or?
Pros:
Creating a Flex mobile project is easier (use Flex 4.6 with design mode to rapidly prototype, 4.7 to develop) and visually let's you drag and drop
You can use data binding and other convieniant built in tools
Like anything else, there's good and bad about using the Flex mobile project as oppose to a complete ActionScript based solution. Mainly, it's a lot easier to customize your preloadeder, your splash screen and other features similar to tht like customizing how your application handles screen. Below is a couple pros and cons of using the Flex mobile version instead of ActionScript.
Cons:
Slower performance
Can't use Adobe Scout, it's an awesome tool for real time benchmarking and profiling. Using the built in one is ok but it doesn't give you theamazing information that Scout provides.
My advice: if you're savvy enough to do everything in ActionScript, then definitely create an ActionScript project, your users will love you for it. Plus, it's not that much harder and it lets you have a myriad of additional control over your components. Also, you don't have to deal with the overhead that comes with data binding ( it generates event listeners, get and set methods and you can create much more efficient ones on your own). There are a number of other things that benefit you by creating an ActionScript version like refactoring and better subversion but those are more of incentives than anything else.
If you plan on making use of the declarative mark-up, built in UI components, and data binding which the Flex framework provides then you should probably start with a Flex Mobile Project. The downside to this approach is that the additional scaffolding of the Flex framework will incur a slight performance hit and will increase the over-all file size of your project.
On the other hand, if performance is critical and you don't need the declarative markup, built in UI components, or data binding provided by the Flex framework, then you should start with a pure ActionScript mobile project. Really simple applications, games, or applications with highly customised UIs would be examples of projects for which a pure ActionScript approach might be more suitable.
FYI, you can use Adobe Scout on Flex apps. Apache Flex now supports advanced Telemetry.
You can also add advanced telemetry to any SWF with the SWF Scout Enabler.

What is Rikulo dart really?

I have been reading the abstracts on the website http://www.rikulo.org but all those cryptic vague statements do not help me. The examples are all about visuals.
I do not understand what this framework is capeable of doing. The big picture is missing.
What kind of apps can i build with rikulo?
Is there any access to the hardware?
Can is use the smartphones sensordata and send e.g. coordinates from my smartphone to a web service?
What are the limitations?
As described in this blog, Rikulo is aimed to provide a structured UI model for Web and mobile programming. We are the same team who developed ZK. With Rikulo, we'd like to take a step further since many things have been changed since we developed ZK in 2005. Also, both Dart and HTML 5 are young. It is an excellent moment to explore the best possible UI architecture for both Web and mobile programming.
For example, we use absolute positioning to give programmers 100% control the layout of UI rather than spending hours to figure out why it fails in certain combination. Another example is "recursive layered structure", such as layout manager and visual effect handling -- rather than ad hoc features targeting specific problems individually.
On the other hand, we don't have many widgets yet. It might be the reason that confused you. As a Apache licensed project, we hope we can have an active community for building widgets and addons, as long as we can really provide a solid and elegant architecture -- it is what we focus now and keep refining.
To access the hardware, you can use Rikulo Gap which is based on Cordova/PhoneGap. To communicate back the server, you can use Web socket or HttpRequest. We will have more advanced support for jsonizing, caching and communicating Dart objects between client and server, but it is not ready yet.
Technically, there is no limitation. Of course, the current number of widgets is definitely not enough, but it will get more in the near future. Furthermore, you always can create them with HTML 5 (and contribute back). However, for mobile applications, one thing you have to keep in mind: the performance won't be as good as the apps written in Objective C. The good is Rikulo is cross platform and your app can be accessed with Web browsers and as a native app.

three.js vs libgdx for 3D web development

Libgdx is focused mainly on Android and is written in java but apparently it can run apps on the browser(webGL?). Three.js is a very impressive javascript 3D library which uses WebGL(or 2d canvas) as well for rendering.
So far I haven't seen any comparisons between this two since they have different focuses, but I would like to know the differences, what can one library do that the other one can not.
I don't think I'm too qualified to talk about Three.js, but I have used libGDX for many projects of mine and know its disadvantages when it comes to WebGL (the browser export).
The first factors to consider is what language you are used to, Three.js uses JavaScript and libGDX uses Java. And although libGDX exports to WebGL, it's only because it uses GWT, you still do the coding in Java.
LibGDX is specialized (as you said) in mobile and (to an extent) desktop applications. If you're goal is to create something that works on the web as well as mobile and desktop then libGDX should be considered. However, if you only wish to program things for the web, then I would really consider just doing Three.js for reasons I will explain later.
LibGDX is made mainly for game development, so if the application you're making is a game, you could consider libGDX, as it makes game programming in 3D nice and easy (and you'll be able to port it to multiple platforms, not only web, but mobile and desktop). But if you're making something else, Three.js may be a better option.
If your platform for distribution is going to be your web version I would suggest sticking with Three.js, because libGDX isn't that good for its WebGL export. One of the biggest issues (which is solvable, but a pain to deal with) is that libGDX does not prevent default browser keys from being used. However, if you do choose to use libGDX, make sure you take a look at this to fix that problem (more or less).
For the most part, if you're main platform is going to be web you'll want to program in a language that is meant for web development. If you program in JavaScript using the Three.js framework the code will be cleaner and faster to run. Meanwhile, if you use libGDX it essentially transforms Java code into JavaScript coding making it inefficient and bulky and will contain many lines of JavaScript code that are either useless or can be simplified. It's not an issue with libGDX (or rather GWT) itself, but rather just something that cannot be avoided when automating programming language translation. To give you an example, using the programming language Haxe, if you compile a HelloWorld Haxe to C++ it contains a bunch of unnecessary variables and methods (in the C++ source code) that you could just get rid of. Same in this case.
So in the end it depends on what you're aiming for. If you plan on sticking with just the web version use Three.js, otherwise libGDX should be considered.

What's exactly is the web part of delphi web script?

I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.

Resources