(Presumably the following question is not iPhone specific, aside from the fact that we would likely use a Framework or dynamic library otherwise.)
I am building a proprietary iPhone SDK for a client, to integrate with their web back-end. Since we don't want to distribute the source code to customers, we need to distribute the SDK as a static library. This all works fine, and I have verified that I can link new iPhone apps against the library and install them on the device.
My concern is around third party libraries that our SDK depends on. For example we are currently using HTTPRiot and Three20 (the exact libraries may change, but that's not the point). I am worried that this may result in conflicts if customers are also using any of these libraries (and perhaps even different versions) in their app.
What are the best practices around this? Is there some way to exclude the dependent libraries' symbols from our own static library (in which case customers would have to manually link to both our SDK as well as HTTPRiot and Three20)? Or is there some other established mechanism?
I'm trying to strike a balance between ease of use and flexibility / compatibility. Ideally customers would only have to drop our own SDK into their project and make a minimal number of build settings changes, but if it makes things more robust, it might make more sense to have customers link against multiple libraries individually. Or I suppose we could distribute multiple versions of the SDK, with and without third party dependencies, to cover both cases.
I hope my questions make sense... Coming mainly from a Ruby and Java background, I haven't had to deal with compiled libraries (in the traditional sense) for a long time... ;)
If it were me I would specify exactly which versions of those 3rd party libraries my library interoperates with. I would then test against them, document them, and probably deliver with those particular versions included in the release.
Two things I would worry about:
-I would want to be sure it 'just works' when my customers install it.
-I wouldn't want to guarantee support for arbitrary future versions of those 3rd party libraries.
It is fine to include a process for the customer to move to newer versions, but if anything doesn't work then I would expect the customer to pay for that development work as an enhancement, rather than it being a free bug fix (unless you include that in the original license/support arrangement).
At that point it becomes an issue of ensuring your specific versions of the 3rd party libraries can work happily alongside anything else the customer needs (in your case a web back-end). In my experience that is usually a function of the library, e.g. some aren't designed so multiple versions can run side-by-side.
Related
I am trying to create a UWP app with dbStorage feature.
I looked at the UWP-Howto : https://msdn.microsoft.com/en-us/windows/uwp/data-access/index, and see that there are two ways of doing this.
Either using the basic sqlite3 APIs (I dont wish to use any 3rd party wrapper libraries)
Integrating Entity Framework with the App.
The latter option does seem to be a better option, since it is a ORM, but I am curious to know, adding it does it shoot up the App size in comparison to using the plain sqlite extension? Has anyone using it faced such problems?
App size should be one of the last things to worry about when creating UWP apps. This size is a one time 'problem' when the user installs the app since it takes some time to download. There are a lot of improvements built into the Windows 10 Store to tackle this problem:
Incremental updates (only update part of your app that changed)
File single instancing (if the file/library is on your system, it isn't downloaded again)
Partial resource downloads (only the language and scaled assets that fit for the device)
More info, see e.g. this Build session.
If you want exact numbers, I would suggest building a small PoC with and without and compare in size (although size will change a tiny bit as well because you write different code pieces to make it work).
But the added size because of using EF Core won't be in the magnitude of 100s of MBs. The packages itself are EFCore.Sqlite 71kb, EFCore.Relational 475kb, EFCore 783kb and these even include multiple dlls, xml, ... so it's only a fraction of that. Together with a few more base packages (Caching, Logging, ...) and maybe a few extra .NET standard libraries that will be used that might not be used when using the basic API you'll have a few MB extra. In my opinion ignorable.
The things you SHOULD worry instead of the initial download time about are:
Application startup time.
Overall application performance.
Performance of the developer (and thus the cost of creating the app).
If you're choice is between the native sqlite3 APIs and EF Core, it would be an easy pick for me (thinking on point 3 mentioned above). Just bear in mind that there are still issues with EF Core and .NET Native (the optimizations done by the store or when you build in Release mode with .NET native toolchain enabled). If you want to publish to the store very soon and have a rather large database, you might have some troubles to get it crash free. If you can sideload the app, just build without the .NET Native toolchain.
Background: I am about to start preparing my 1st framework for my clients, so they can easily integrate it into their apps and fetch data from my servers without dealing how communication with server is working. I chose ASIHTTPRequest library for communication.
Question: how should I deal with ASIHTTPRequest or any other static library - make it a part of my framework or let adopters link against it themselves in their projects?
I'm opting to make it a part of my framework, so I can prevent users from setting breakpoints in ASIHTTPRequest and easily access/log connection frames/data. But what would happen if my clients will need this library for their own purposes? Will they be able to link it second time? Won't it cause any run-time collisions?
Sorry for wording... Please let me stand corrected if I'm confusing any terms :)
Look at how ASIHTTPRequest handle it :)
They make you link against lots of the iOS frameworks but they don't ship them with their download.
However, they do ship code for Reachability with their library - if you don't already have it then you can include it. If you already have it in your project then that's OK too.
I would ship the source of ASI in a seperate folder - then your users can either include it or not.
That also has the benefit of ensuring that the version of ASI they use will work with your library ;)
(see the ASI docs here)
There are two different types of frameworks to consider, so I would do two things:
For any third party library like ASI that you use, include a
directory with the source as deanWombonurne indicated. Make sure to indicate which version of the library you have included if it is not clear (add a VERSION) file if needed or name the directory).
For Apple frameworks, include a manifest file somewhere that gives a
list of all the Apple frameworks they should include in their
project to satisfy your framework requirements.
I'm interested in creating a basic web application (for learning, but I want to finish within a few months), and I've read that using a web framework can make that task much easier.
After reading about different frameworks online, it seems to me that using frameworks would hide a lot of detail on they work. I fear that if I use a framework, I won't really know how my website is running.
Is it important to understand how frameworks do what they do, or am I worrying too much? (eg. I don't know how the Linux kernel works, or the C compiler, etc.)
Even if you don't have a particular interest in web frameworks, I would say it's good to play with a few and then crack them open if only for the exposure to new design patterns and solutions that can be applied anywhere in development. (MVC in particular when talking about most web frameworks)
It is (to some extent) important to understand how frameworks work, but you'll never learn that without using them.
So, start using some framework and you'll get basic understanding of it. And then, if you have interest, you can always dig deeper into it (maybe even submit patches and participate in its development). But not in the opposite order.
Using your analogy, you don't become Linux kernel developer without being Linux user for some time.
I want know about how to create dynamic library frameworks for iphone..
Any ideas about this..please guide me...
Dynamic linking is forbidden if you want to deliver to the App Store (apart of the Apple provided libraries and frameworks, of course). Only static linking of external libraries is allowed by Apple.
Edit: (quoting myself from a comment to a different question) The reason is security: since a dynamic library can be loaded and unloaded at runtime you could download additional executable code and load it (think plug-in). This could get compromised by a hacker and then having malicious code executing on your phone is a very bad thing. It would also make it possible to add unapproved features to an approved app. In short: in this environment, Apple considers dynamic linking to be a Pandoras box that must be strictly controlled, otherwise it could compromise security and I agree that it does make sense on the phone.
This simply isn't supported for various reasons.
Use static libraries instead, or compile the source directly into your project.
I have a set of functionality (classes) that I would like to share with an application I'm building for the iPhone and for the Blackberry (Java). Does anyone have any best practices on doing this?
This is not going to be possible as far as I understand your question - the binary format for the iPhone and Java are not compatible - and even for a native library on a blackberry device.
This is not like building for OS X where you can use Java unfornately the iPhone doesn't support Java.
The best idea is probably to build you library in Objective-C and then port it to Java which is an easier transition than going the other way. If you programme for Objective-C and make sure you code has no memory leaks - then the changes are not so complex.
If you keep the structure of your classes the same then you should find maintenance much simpler - fix a bug in the Java and you should find it easy to check for the same bug in the ObjC methods etc.
Hope this helps - sorry that it is not all good news.
As Grouchal mentioned - you are not going to be able to share any physical components of your application between the two platforms. However you should be able to share the logical design of your application if you carefully separate it into highly decoupled layers. This is still a big win because the logical application design probably accounts for a large part of your development effort.
You could aim to wrap the sections of the platform specific APIs (iPhone SDK etc.) that you use with your own interfaces. In doing so you are effectively hiding the platform specific libraries and making your design and code easier to manage when dealing with differences in the platforms.
With this in place you can write your core application code so that it appears very similar on either platform - even though they are written in different languages. I find Java and Objective-C to be very similar conceptually (at least at the level at which I use it) and would expect to be able to achieve parity with at least the following:
An almost identical set of Java and Objective-C classes with the same names and responsibilities
Java/Objective-C classes with similarly named methods
Java/Objective-C methods with the same responsibilities and logical implementations
This alone will make the application easier to understand across platforms. Of course the code will always look very different at the edges - i.e when you start dealing with the view, threading, networking etc. However, these concerns will be handled by your API wrappers which once developed should have fairly static interfaces.
You might also stand to benefit if you later developer further applications that need to be delivered to both platforms as you might find that you can reuse or extend your API wrappers.
If you are writing a client-server type application you should also try and keep as much logic on your server as possible. Keep the amount of extra business logic on the device to a minimum. The more you can just treat the device as a view layer the less porting you'll have to do over all.
Aside from that, following the same naming conventions and package structure across all the projects helps greatly, especially for your framework code.
The UI API's and usability paradigms for BlackBerry and iPhone are so different that it won't be possible in most cases to directly port this kind of logic between apps. The biggest mistake one could make (in my opinion) is to try and transplant a user experience designed for one mobile platform on to another. The way people interact with BlackBerrys vs iPhones is very different so be prepared to revamp your user experience for each mobile platform you want to deploy on.
Hope this is helpful.
It is possible to write C++ code that works in both a BB10 Native app and an iOS app.
XCode would need to see the C++ files as ObjectiveCPP code.
I am currently working on such a task in my spare time. I have not yet completed it enough to either show or know if it is truly possible, but I haven't run in to any road-blocks yet.
You will need to be disciplined to write good cross-platform code designed w/ abstractions for platform-specific features.
My general pattern is that I have "class Foo" to do cross platform stuff, and a "class FooPlatform" to do platform specific stuff.
Class "Foo" can call class "FooPlatform" which abstracts out anything platform specific.
The raw cross-platform code is itself not compile-able on its own.
Separate BB10 and XCode projects are created in their respective IDEs.
Each project implements a thin (few [dozen] line) "class FooPlatform" and references the raw cross-platform code.
When I get something working that I can show I will post again here...