I have downloaded muPdf source. we want to use in our android application for our company.. can I use the library and android source as reference for our application.
Please dont mind if I ask stupid question, because Im confused after reading the licencing information.
Thanks
Its open source code under the Affero General Public Licence. If your application or usage conforms to the AGPL then you can use the library freely.
If it does not (eg you intend to sell your application, or you intend to use portions of the source without making your own source open source under the AGPL) then you must seek a commercial licence. Artifex has a range of different licencing options, including one specifically designed for Android/iPhone app developers.
If you feel you need a commercial licence, or want to discuss it, then you should contact sales#artifex.com.
Related
Is it possible to incorporate one iPhone app into another in order to redistribute it?
We're going to publish few apps owned by other developers and need to create some pre-rolls with our branding and some other similar features. The original developer could build the app for us, but won't provide us with a source code.
Sorry if the question sounds stupid, we haven't very big experience in the field, just need to clarify some things
Thank you!
No you can't. You are only allowed to execute your own app, you can't embed an other app in your bundle.
It is not possible to embed an app into another app, or better, you could do that, but Apple would reject it and anyway you would not be able to launch it on a non jailbroken device.
More to the point of your specific case, if you have only the binaries you could try and modify the resource files (i.e., .nib and .strings files) to modify the UI to some extent. Of course, you would then need to regenerate the signature for the app (and hope that everything works ok).
It's just a thought, but maybe you could include the other developers apps as static libraries. The advantages would be that the other devs wouldn't have to surrender their sources, you wouldn't face any code signing and bundle id related issues and including static libraries is perfectly safe.
The only disadvantage would be that the devs would still need to deliver the content seperately and they need to learn how to build a static library. An entry point for each app / each library to call it would also be needed, maybe even a small interface to allow the container app to learn about the individual apps status, to cancel them etc.
As I said, this is just an idea, there may be issues with that approach that I do fail to see right now. But maybe others can comment on this...
You might want to check out this link to learn a bit about building static objective c libraries.
Check apples Custom URL scheme, it might find useful for you. Just help=> http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
Is there a sane way to develop a cross platform Mobile app? We want these to be native apps on each platform, and not necessarily some kind of web page.
Currently we're thinking to split it into two languages:
C# backend (business logic)
--> Standard C# app for WP7
--> App built on MonoTouch for iPhone/iPad/etc.
Java backend (business logic)
--> Standard Android Java app (MonoDroid version of C# not ready
yet)
--> Standard Blackberry Java app
We could also develop initially in C# and use one of the conversion tools out there to get our C# converted into Java as a starting point.
Is there another approach? Our skillsets include mainly include a strong C# .Net background, and minor Java experience.
We don't really want to go low level and use something like C/C++ to get the job done. These are usually going to be simple LOB applications that communicate to some web service.
Side Question: how do game devs like the makers of Angry Birds do it?
UPDATE:
MonoDroid is now officially released. So it seems you would only need to use Java for the BlackBerry. We are considering not developing for BlackBerry at all, because developing for the other 3 platforms has been simplified. There is definitely some cost involved, as MonoTouch and MonoDroid are both $399 and you would also need a license for Visual Studio (this doesn't include cost for App store, etc.).
There's no good simple answer that I know of for all mobile platforms. You can use development environments like Appcelerator Titanium, which cross-compile to native code on various platforms (right now, for instance, I think Titanium supports iOS and Android, with plans for Blackberry). However, these usually have a limited API that you have access to, and you still end up needing to design different UIs for the different platforms (in my commercial work, I have never successfully used such a platform)
You could also design all the business logic in a web-services back end, and then just write "thin client" apps for each platform. This works, but of course requires network access when the end user wants to use your app. (Usually it'll be there, but sometimes may not)
Ultimately, I usually end up doing what you propose -- writing the basic business logic in a couple of different languages as generically as possible, and then bundling that in with custom UI/device code for each platform. Haven't found a better way myself....
(BTW, I believe games like Angry Birds are written largely in OpenGL and then loaded onto the OpenGL processor on each platform. But I could be mistaken...)
Those are some great answers. I agree, x-platform development is still very primitive. I'd like to add 2 points:
1) You do not need to write your backend in different languages. Choose one language (based on your comfort level, performance etc. criteria) and then connect from your platform-specific apps directly to the backend. If your backend is server-side code, one way of talking to it would be via XmlHttpClient. If it's a piece of native code common across various apps and is written in say C++, you can use JNI from Java and wrapper assembly from C#.
2) Another reason for avoiding x-platform tools is that you'd always need to wait for them to support the new APIs released by the platform vendor (Apple, Google, MSFT etc.). Once these companies release new APIs, the tools will need to be updated and only then will you be able to use the new APIs.
I don't think this is (easily) possible, if you're not using some HTML5 (jquerymobile etc.) in a WebView in your own app (looks like a real app, but still you will somehow see that it's not) instead of the normal browser. You can still use some native API from the device (accelerometer,...).
There are (commercial) platforms like Sybase Unwired Platform that help you in generating some client code. Afaik for Blackberry and Windows Mobile even some UI can be generated out of the business objects on the server. But to me it sounds that this might be too heavy-weight for your case.
Regards,
Martin
We're currently negotiating an outsourced iPhone development - and one of our requirements is that we also get the project source at the end of the development to allow us to enhance/update once the initial app is released.
The developer does not want to release the source of their own common libraries - which is understandable - and have said that they will have to write new code to replace those libraries.
However - on other platforms, it is possible to include libraries as pre-compiled software so that the source code is not necessarily released. Is this possible with iPhone app development? And if so, is it easy to implement?
Yes it is perfectly possible look at the admob or flurry libraries for example
To make a static library look here http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
As Apple has removed the restriction for java and flash should I go for these tools or just continue developing iPhone/iPad apps using Apple tools(Xcode, objective C .. etc).
I want to know the benefits of using apple tool instead of java or flash.
Thanks
Java is not an option anyway. There is no Java runtime for the iPhone that you can use to produce apps.
This is a no brainer. For iPhone, use Apple's SDK. You'll get latest APIs first than in any other platform, better performance, and, what's even more important, you are sure that Apple will keep pushing its API. With other products (like Java, Flash or Mono) you will always fear they changing their policies when they want. No guarantees.
It really depends on what kinds of apps you are making.
If you are just making a basic app, that you want to look like the standard Apple apps, you shouldn't switch.
If you really rely on Flash as a base, you should use that.
If you have little experience with Objective-C and prefer to code in C#/.NET, you may go for MonoTouch.
It really depends on your preferations, but if you want the most stable, reliable, and supported platform, you should go with Objective-C.
In my eyes, you should really only be using anything other than the standard Objective-C if it is utterly necessary, as others have pointed out; with Apple, you get the latest API's first, better performance, etc.
For new development I would jump in and use Apple's frameworks with Objective-C. If you're entering a new country you should speak their language. However, which development framework you choose will be largely dependent on whether or not you have an existing product. If you're just trying to target a new platform with an existing code-base it may be in your best interest to use an intermediary framework like MonoTouch or Adobe's Packager for iPhone.
If your codebase is Java, you'll be starting from scratch in Objective-C. Java is not currently available in any form on iOS.
If your codebase is in ActionScript 3, you may want to explore Adobe's Packager for iPhone. It will likely have a shorter path to market if your are porting an app already developed on ActionScript 3, but you will always be at the mercy of Adobe's intermediate layers. I know less about the Adobe bindings and how your application actually compiles, so I can't speak to any additional technical-risks there.
If your codebase is in C#, you may want to look at Novell's MonoTouch. Again, this may result in a shorter time to market. You still need to develop on a Mac (MonoDevelop only works on a Mac), and some .NET APIs are not available on Mono.
In any other circumstance I'd pick up Objective-C and use Apple's SDK directly. It's always tough to learn a new language (especially one as different as Objective-C), but it's worth it in the end.
Use the tool that will make the most sense for your goals and the experience you want to provide your users. Apple's lifting of restrictions only removes one risk: that using a framework not endorsed by Apple will be the sole reason for App Store rejection. The lifting of restrictions will not remove other risks that may exist like:
Continued support by third-party vendors (Novell, Adobe) of their frameworks.
Inability to target/test against the newest version of iOS until third-party frameworks add official support.
Apple doesn't want anyone to create iPhone apps outside of the Xcode/Objective-C environment. How can they actually enforce this?
If the non Xcode IDE, for example Unity, compiles to an iPhone executable, how will Apple know which dev environment you used to create the app? Can they have Xcode compile some sort of signature into the executable that no one knows about?
For tools such as unity, corona, flash, and other platforms used to 'generate' iphone apps, Apple may be able to 'decompile' and examine your app (look at patterns of generated functions, etc). From this, they might be able to guess that your app was generated with such a tool.
In the limit, this is impossible. Consider the following: I write some script code to generate a bunch of objective-c code. Then I manually import the objective-c files into xcode and build the app. How would apple be able to distinguish the script-generated code from human-written code? Maybe I just tend to write code that happens to look machine-generated. There's no way for apple to determine whether the code was "originally written in objective-c, c, c++ or javascript" or not, yet this would still, technically, violate the agreement. That's why the 3.3.1 part of the agreement is nonsense.
Most automated systems do things a particular way, which isn't hard to detect. If you've ever looked at the PHP or JavaScript code Adobe Dreamweaver generates, for example, you know how easy it is to find stuff like this.
Apple is doing this to prevent people from using Adobe's Flash development framework. It should also be noted that Apple's decision to limit Application Frameworks like this is causing the DOJ/FTC or some government agency to start an informal inquiry into monopolistic practices.
From this article:
"According to the Post's Hollywood source, Apple's ban of Adobe's Flash technology on the iPhone and iPad is what prompted the government to poke around. "
They really don't have an issue up until now with other frameworks because Adobe didn't have one based with the Flash environment. Now that there is one, Apple is going to restrict anything that talks/looks/smells/acts like an Adobe Flash app on the iPhone. In my opinion, they won't do anything to other frameworks, but they'll enforce the rule just for Adobe. Which brings up the whole monopolistic practices thing.
I believe that many of these translator tools have some kind of common runtime function library which take care of the portions that could not be translated 1:1. Those function could then be pretty constant regardless of your application. That way there would be no real need to decompile the app. but instead just look for usage of those function signatures.
FWIW I find the whole idea of limiting user's choice of tools is a bad move.