We (our team) saw that it's possible to include standalone app to a plugin. The app is used to modify Petrel's data in the specific way. See for example these plugins:
http://www.ocean.slb.com/Pages/Product.aspx?category=petrelgeophysics%28Petrel%29&cat=Petrel&pid=PCPT-B1%28Base%29&view=grid
http://www.ocean.slb.com/Pages/Product.aspx?category=petrelgeophysics%28Petrel%29&cat=Petrel&pid=PRPW-B1%28Base%29&view=grid
We want to do the same thing so there are questions:
How the plugin perform editing Petrel's data?
Does Petrel (Ocean) provide any mechanisms for IPC or should we develop our own architecture for communications between managed plugin code and native app process?
For most Petrel data, it is only safe to modify them inside the main thread of a Petrel plug-in.
If you already have a native process that does the number crunching, you will need to implement your own way to share the data between the plug-in and the native process. Eclipse does this by file sharing. If the overhead of IPC outweigh the actual computation, you may want to consider refactoring the native process to make it run inside the plug-in.
Related
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
I am trying to manage my dependencies of my play framework application. I am trying to remove/update some jar that exists in my classpath. Does that even possible?
It would be great to get an explanation of how does play framework manages classloaders. I understood that in order to obtain hot redeployment of code in development mode Play is restarting the application classloader and loads all classes again. Does it right?
Thanks a lot!
It's not really Play managing the hot reloading but rather the Play SBT plugin.
A Play application's main method is in play.core.server.NettyServer. The method receives a reloader of type SBTLink and each time a request hits the server, the application delegates the task of checking if there have been any code changes to the reloader.
If there has been a code change then the existing classloader is removed and replaced with a new one which includes the updated bytecode. The application is restarted but, of course, the JVM is not.
Play is not designed to provision dynamic swapping of Jars at runtime. For this, you would need to look at things like OSGi (which I would not personally recommend after a few years of working with it).
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
As far as I see every time I make a change, for example the value of a configuration variable, I have to
Make a copy of the change in each project (webapp, Android, IPhone, etc.)
Build each project
Distribute each project (besides the webapp)
I have found PhoneGap build which seems to be a great solution for the mobile part. But it's still beta and it doesn't solve everything. I still have webapp's code, which is not exactly the same.
Do you know techniques, tools or tricks, which help to improve this process?
Thanks in advance.
We are currently developing a web/Android app using PhoneGap and Sencha Touch (iOS is coming soon). So far our approach is as follows:
We have one project per platform plus several additional toolkit projects.
One platform is "primary", web in our case. This is what developers mainly use to develop and test the app. We're using jsTestDriver for testing.
During the build, the app is packaged for web in the first step. We're producing several artifacts here (.war file, tests in a .jar file).
"Secondary" platform projects do not include the source code. It gets unpackaged and copied to the right places when projects are built. This also includes tests from the primary platform.
Platform projects contain some additional code - normally only testing code, app code itself is currently cross-platform (not sure if it will stay this way).
So we're doing it mainly through advanced build scripts. We're using Maven for web and Android. iOS is coming soon (into our work, I mean), so we'll be looking for some sensible build tool there too.
We're building our projects using Hudson continuous integration.
What I have to admit is that this whole environment (multi-project Maven builds, JSTD, multi-node Hudson) is a hell of a setup, took quite an effort to figure it out.
I have recently been browsing frameworks such as JavaScriptMVC, qooxdoo, Sproutcore and others alike which are using javascript to create desktop-like apps in the browser with minimal, or none css/html (depending on the framework).
What I know of titanium is that it uses html/css for the views, and language of choice (javascript, ruby,python,php) for everything else. Then it gets compiled(?) into a native app.
What are the quirks? if any?
Is it necessary for the user to install some sort of a runtime to execute the compiled app?
I suppose javascript is the prefered language, but how are the other ones handled?
For example, which Ruby interpreter would be included, would I be albe to use the ruby stdlib or external libraries? Would it affect the speed of the app? I.e JS > Ruby in terms of speed.
Since the views are CSS/HTML, would it still be necessary to style the elements, add them effects via JS librarier to achieve a widget-like feeling? Or does it come with some pre-made settings/classes for that?
I am not sure if it applies to the desktop package, but is there some syncing with the appcelerator's server required? What would it be necessary for?
I am sorry if the questions sound stupid, but I didn't even realise there are than many tools until recent. I am ultimately looking for something which is easy to use, has an option to work with a back-end server for data exchange, looks preferably good 'out of the box' or doesnt require that much work to get it themed nicely and works on mobile as well as desktop devices.
With Titanium you build your app out using javascript. Titanium ultimately generates its own XCode project for you that is compiled and deployed to a device.
The user does not require any runtime be installed prior to installing your app.
Unless your building custom modules to hook up your own controls you stick with javascript.
Your javascript calls end up as native controls, early versions required css like styling due to reliance on webkit but this is no longer the case.
There is no IDE but it does come with an app to create Titanium projects, test in emulator, deploy etc. It also talks back to HQ for updates.
In answer to (2), Titanium Mobile is Javascript only, but Desktop also supports Python, Perl and PHP.