I know the title might be a little misleading so if you find better words for what I mean, please feel free to modify it. I take the concept of 'target' from Xcode.
I'm an iPhone developer now turning to android one. With Xcode I can do the following, supposing I have a list of apps in which users grow different plants:
I can set different target, e.g. apple, bear etc.
for each target I can choose to load different database/UI images, they are all in the project file with same names but in different folders, and I can set which target uses which files.
at building phase I simply choose targets and click build, and then I can have a list of my apps.
The advantage of this is I don't need to change anything in code, just grab the resources from designer and change a little project setting, and all is done.
Now with eclipse I can't find out how I can do that so simple. I have to remove old resources and copy new ones there to build for a different target. This takes too much time when I have to make an update for 20 apps. So is there a better to achieve what I'm requiring? any plugin for eclipse or there are some easy ways that I don't know yet?
I got a solution with Android Studio's Gradle Build System i-e defining different flavors of my app and then using build variant configuations, producing different apps from same/shared code base, resources etc.
As per Android Developers Docs
The build system uses product flavors to create different product versions of your app. Each product version of your app can have different features or device requirements. The build system also uses build types to apply different build and packaging settings to each product version. Each product flavor and build type combination forms a build variant. The build system generates a different APK for each build variant of your app. Now one can have two or more product flavors e.g (paid flavor, free/demo flavor) etc for one single project with same code base.
For more information See Build Variants & Product Flavors Doc
I started a similar topic and added a bounty, so I even got responses.
Here is the topic with explanation of the problem and possible solutions that I found on the web. These are mainly library projects and broadcast receivers. Maybe library projects will work for you?
There is also a satisfactory answer that I got with a solution for Android/Eclipse. It proposes using SharedPreferences for determining which code/image/package is invoked and which not. The problem I see with it is that the entire code and resources must be in the app, so this gets quite large in case that one has a lot of different images.
Maybe there will be other helpful answers there, you can have a look after a couple of days. What I already know is that there is no such thing like targets in Eclipse... In Android Studio there are modules which seem to be similar, but that does not really help us.
Related
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I have looked for similar questions, but could find none other than the difference between solutions and projects. Mine is on the same level, I suppose, but is slightly different.
I'm a previous Java developer thrust into C# recently and I am the sole individual charged with setting up source control, project standards, etc. etc. and this is my first go with Visual Studio (using 2010 Pro).
I understand a solution is a "container" for related projects, but I am unsure the best practices of adding projects to a solution which are related, but are of a different type.
For example, would I place a web project in the same solution with a desktop application or mobile app if they are related (rather near identical) in function? They are basically the same app, but in different formats. They may use the same classes (for a contrived example, a Person class).
To me, they seem obviously related, but are different applications, so it would seem they should be in different solutions.
I appreciate any feedback offered.
Thanks in advance.
Those apps should be in one solution, expecialy if they share functionality, common projects etc. Quite good approach is to group projects within a solution using solution folders, for example "Common", "Web", "Mobile", "Setup" etc. This way you can have logical groups inside solution.
I would place them in the same solution, since this makes it easier to have a common class library as one project in that solution.
There are no rules for this so there is no right or wrong answer. It all comes down to how you want to organize your code. We commonly have web apps and console apps in the same solution because they are functionally tied together and share code so the type of project really does not matter.
I would place them in the same solution. You can create different configurations to build each application or build both of them at the same time. This allows you to change the class and verify changes made to the class will work for both applications.
Also if you start to see functionality start to duplicate across applications it is easier to create new classes and project that can apply to both applications.
You can throw everything in one solution. This is convenient if you often have to debug the library and application code together, but if the solution has many projects it can become unwieldy.
One approach is to treat the solution as 'that which will be installed as a unit.' Then your common library will go in one solution, and your mobile and desktop apps in their own solutions. This keeps solutions smaller, but it can be inconvenient when you are developing everything together-- so it works best when the library is very stable.
I know some of the tutorials for creating Xcode project templates, for example this one here: http://robnapier.net/blog/project-templates-364
This is the best one I could find. All others basically repeat the same info, or are no longer up to date, or worse tell me that even they don't know what they're doing. Possibly useful tools that are linked to here and in other places are no longer available.
I keep running into roadblocks, and would like to gather as much information as possible on the process of creating Xcode project templates. Info that is most importantly up to date (at least it must be relevant for Xcode 3 or higher).
For example, what I'd like to see is:
a description of the
TemplateChooser.plist and similar
plist files and what these options do
(in my case, once I add a
TemplateChooser.plist, my project
disappears from the Xcode project
template list)
how to create a project template that references another .xcodeproj (when I do that, the other .xcodeproj appears in the project template list even though it doesn't use the special naming convention)
processes that can be applied, for example is it possible to run a script during the creating of a project from a template? This would be useful to unzip certain files into the newly created project.
If you have the answer or suggestions to any of the issues above, I'd appreciate that. Otherwise any link to good Xcode project template resources would be highly recommended. Especially if there is an official documentation from Apple - I haven't found one yet which seems to imply that project templates are undocumented.
Have you seen these:
http://www.sodeso.nl/?p=895
http://www.codeproject.com/KB/iPhone/CreatingXcodeProject.aspx
If you say you have searched, I'm pretty sure you've already seen the links but these are the best resources I could find with my 'googlabilities'
You might try contact this guy - http://linkedin.com/in/mottishneor he has some related messages around the web
The links suggested by FX are also not bad at all!
There is indeed little XCode template info out there. What I have found of interest are the following links (I documented myself on the topic, but haven't yet gone any further):
a Google Code search reveals a few examples, but not much
in particular, I found interesting to look at the code provided by Three20; they have some basic examples, like here
referencing another project worked for me, so maybe you could open a specific question about that giving more details?
there is information scattered on the Apple mailing-lists
there is no official documentation from Apple, as is evidenced by the lack of results to this query
I'm sorry if this is not a Enlighting, concise answer. As you said, it's not well documented, and sources are all over the place. I just hope I could highlight some places to find information that your own searches might not have reached :)
I don't have a Mac anymore, so this is as much as I can give you without testing this myself. As far as I can tell, Xcode templates are undocumented by Apple.
This guy has some guides for messing with Xcode templates but the info is pretty sparse. My suggestion for working with templateChooser.plist is to try to only edit that file in the interface builder.
This guide is a good example of how to add a reference to another .xcodeproj. For the reason you were having trouble adding a reference to your project we probably need more information.
If you scroll way down in this doc you can that each template already includes a script called myscript.sh. This script will show up in the scripts menu for projects built with that template. That isn't quite as convenient as running scripts automatically, but it's better than nothing.
In conclusion, Xcode template documentation is a nightmare. It looks like there are a lot of powerful features there, but they are obscured because of lack of user friendlyness and because documentation lags far behind Apples updates of Xcode. It just doesn't seem to be a priority for them. I hope this helps.
And yet another video link http://howtomakeiphoneapps.com/2010/10/how-to-make-custom-xcode-templates-with-video/
I had been following this guide to get areas with multiple projects setup:
http://msdn.microsoft.com/en-us/library/ee307987(VS.100).aspx
I was stumbling on the step where you modify the .csproj files to enable the AfterBuild configuration. My googling led me to this post from Steve Mosely:
http://avingtonsolutions.com/blog/post/2010/04/03/JQuery-AspNet-MVC-2-Multi-Project-Areas-and-Other-News-Minutia.aspx
So far the only hang up I had was that
I had set up my solution to
incorporate multi project areas which
was supported in the MVC 2 preview
releases of Areas. However, when the
RTM came out it was no longer
supported. I searched and searched for
solutions to my dilemma, but the only
thing I could find was post by
Jonathon who basically had the same
experience I had, and a reference to
an obscure message on a message board
saying (by what appeared to be some
one from the ASP Team) that it was not
supported. To date, I haven't found
any more formal post or article saying
that was not the case.
Is this true? Did this feature get removed from 2010 MVC2? I haven't been able to find a definite answer.
They were removed in Preview 2. The only supported use of areas are single-project areas.
You can reference the Build assembly in the "Futures" download for both MVC2 and MVC3. Of course, multiple Areas are supported in the RC within a single project. I completely disagree with Levi that it didn't make sense to merge multiple projects. It makes total sense when you develop large applications and desire to break up the functionality into "modules", or "mini applications". Simply research topics like "OO programming", "composition", "modular", "dependency injection", "inversion of control", "aspects" and related frameworks like "MEF", "Unity", "Prism", "Composite Application Framework", SmartClient application block, etc. (not to mention all of the incredible non-MS frameworks, but mentioning one means not mentioning another and people get all touchy about things like that...).
Notes: 1) The documented MSBuild tasks are not included in the project files in the release, so you must find and add them and 2) The futures assemblies are not strongly named, so you will want to change the MSBuild tasks to use the "PublicKeyToken=null" in the "AssemblyName" paths.
I'm new to this so please make allowances.
I'm trying to build Audioslicer which seems to need a framework called IntervalSlider. The IntervalSlider build fails with:
framework not found InterfaceBuilderKit.
However, the framework seems to be present under the Frameworks group with the necessary headers.
Can anyone suggest what I'm doing wrong?
Thanks
Well, this looked interesting so I downloaded the source. I built it and got an entire slew of build errors.
It looks like
According to source forge, this project hasn't been update since 2006-12-04 and the default SDK is still set to 10.4.
This project uses a bunch of uncompiled libraries/frameworks which need to be compiled to work. Some of them may no longer compile now nearly 4 years later and on new hardware/OS.
This is a complex project which mixes, Objective-C, vanilla C and C++, so it's not the kind of project a novice can reasonably expect to get working. (I'm not even sure I could get it updated.)
In short, this looked like a good idea in its day but the project has gone silent, stale and out of date. You'll need to find an alternative unless you want to spend weeks or months (1) learning how to build such a complex project and (2) tracking down all the updated versions of libraries (assuming they exist.)
I advise looking for another solution. Too bad because this looked like a really neat idea. Such is the fate of a most FOSS. It takes too much drudgery coding to keep something like this up to date. All the fun in coding comes from the creation. Maintenance coding is about as fun as washing the dishes. Few are will to undertake such a chore year-in-year-out without pay.
In the future, always check the last project update date. If its more than a year or the before the last major OS rev, expect problems.