I am not entirely sure if this is the appropriate place to ask this question, but given that CocoaPods is a third-party Xcode plugin not made by Apple is CocoaPods ever used in the professional computer science industry? I know several apps made by fellow individual developers that utilize CocoaPods because it's one less headache (same reason I like the idea), but is it even worth getting familiar with if companies you are interested in working at that make iOS apps don't even use it? Or do companies not care and leave it entirely up to the developer?
Cocoapods is just a tool to find, clone, build, and link against app dependancies. Ultimately, it just creates an .xcworkspace where all of the dependancies are linked to your main app. While Cocoapods isn't a first-party tool, it's only job is to create and configure an .xcworkspace, which is a first party tool. Everything Cocoapods does could be done manually using Xcode.
It's also worth mentioning Carthage as another alternative for dependency management. Carthage simple clones and builds frameworks, it leaves it up to you to drag them into your .xcodeproj and link them. This is a less intrusive approach in that it doesn't create or require an xcworkspace.
EDIT: To address your specific question, yes, both Cocoapods and Carthage have widespread, almost ubiquitous use in the professional world. These tools have become the defacto standard for managing dependancies in Xcode. While you can get by without them, doing this all manually is error prone and wastes time when we have established conventions.
While I can't speak to closed source software such as Google's apps, the fact that they offer pods is a clear indicator that they expect you as a developer to use them. You don't see any instructions from Google on how to setup/build their frameworks from a git submodule now do you?
CocoaPods is a dependency manager for Objective-C and Swift. Many developers add their libraries to CocoaPods. By using it, you're enabling your projects to scale in a reliable way.
You don't have to use CocoaPods. You could always manually add a library to your project, but CocoaPods has become a standard in the professional iOS development industry for its elegance and dependability. CocoaPods is sponsored by big companies, like Capital One. Stripe uses it (http://github.com/stripe/stripe-ios). So does Twitter (http://dev.twitter.com/mopub/ios/getting-started).
CocoaPods is not very hard to learn at all if you want to get started in it. Yes, it seems scary because it creates an xcworkspace, but it only takes about two minutes to first start using it. And for the record – you're simply working on your project by opening up your xcworkspace instead of xcodeproj. Nothing too frightening ;)
The official getting started guide: https://guides.cocoapods.org/using/getting-started.html
A helpful tutorial that walks you through it: https://www.raywenderlich.com/97014/use-cocoapods-with-swift
Related
I have some xamarin.forms 1.xx( I dont know which version) project on multiple platforms Android and iOS. And I've been asked to upgrade it to the maximum available right now version of xamarin.forms.
Therefore, I have 2 questions:
1) How to determine which version of forms I'm using right now (I'm working in Windows environment using Visual Studio 2015 ).
2) How to migrate/update to newest version of forms? (step by step, if it's possible). I have no idea how the result of that kind of operation supposed to look like, cuz I have never done anything like this before in my life. And what the best practices are?
What I've done is opened VS2015->Help->Xamarin release notes, however there was nothing about version of Forms I'm using. Also, I went to the official xamarin website and there was no guide how to do that. I also tried to look at the release notes the last Forms update and trying to find and fix differences, but my project is so big and I thought that this way doesn't seems right.
I'll answer first the What are the best practice regarding upgrading a Xamarin.Forms application? first and then address your other concerns.
I recently upgraded from 1.5.1 to 2.3.2, and from my experience, this is the steps to go through:
Decide which version you will upgrade from and to.
Read the change logs for all stabled releases between these two versions and look for breaking changes/bugfixes. You can find the release notes on Xamarin's website or on NuGet's website too.
Check regularly for new releases on the Xamarin.Forms forum and check if any reported issues may affect you. Every time Xamarin makes a release, there is a thread full of comments from other developers that may have encountered issues you might be interested in.
Using your favorite versioning software, make sure that all local changes are commited or stashed and create a new branch for your Xamarin.Forms upgrade (you don't know how long the upgrade will take and you still want to be able to send patches during the process)
Upgrade: Read the Important notes at Xamarin.Forms 2.3.2 release notes, especially the When upgrading Xamarin.Forms take care not to simply "update all" as ... part. Remember to upgrade on your PCL project, on your iOS project and on your Android project.
Test your whole app on as many devices as possible and for the longest possible period before you merge your branch back into your development/master/Main branch and address the potential incompatibility issues that may have been created in your development/master/Main simultaneously.
Step 3 is very important as it will allow you to reset back to your starting point and restart if you should fail to upgrade for whatever reason.
Xamarin.Forms is moving fast so it's important that you always keep an eye on what's going on even if you don't upgrade.
Which version am I using right now?
You can check that in the NuGet package interface or in the packages.json file in your project.
Good day! I became interested in the tool from Microsoft vsimporter. There was such a problem: when I try to convert .xcodeproj project .sln project in the command line the message appears "The "project" workspace does not contain any schemes". All the schemes are in place. This problem occurs randomly, because It succeded to convert two projects, but with the other two the problem above. I can not understand because of what it happens. If anyone faced with an identical problem I will be glad to any hint!
The problem you're encountering is likely due to the presence of CocoaPods – was your Xcode workspace file generated by CocoaPods? The bridge currently does not support CocoaPods because of limitations in its clang compiler front end, but it's a request we get a lot so we're investigating adding support. Try removing CocoaPods and including your third-party libraries manually. If you run into issues, feel free to get in touch by filing an issue on Github – it's the best way to talk directly to our team. Thanks for checking out the bridge!
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.
Is there a decent Subversion client available for XCode? I am so tempted to write my own as of this morning after having a conflict on an update. I've done merges manually editing the ">>> mine" and "<<< theirs" markers but there has GOT to be a better way in this day and age. Does anyone know of an easy way to resolve conflicts graphically? It seems like SCM conflicts and svn history queries are my two most missed features in all of the Mac SVN clients I've seen so far. I use Versions and sometimes the built in XCode SCM support. I've also looked briefly at Cornerstones web site. (Is Cornerstone any better?) Does anyone have any ideas?
I'd suggest using git-svn with GitX for most things. The GitX commit interface is so nice it's really hard to go back to anything else.
For conflicts I use Emacs, which offers really nice, fully editable, color-coded 3-way merge.
You also might check out the WWDC 2010 videos/slides (free at Apple's site if you're a registered developer) regarding SCM support in the upcoming version of Xcode.
As a GUI, SmartSVN offers a basic conflict editor (though I find the the application very slow to refresh on a large source tree). Often I find myself going back to Emacs which has support for subversion via Psvn.el, and that has a very capable 3 way diff with ancestor revisions, custom region skipping and other goodies.
Me and my team are starting to build up a few re-usable scripts. They're re-usable within our org only as they work with proprietry apps and our particular server environment. So not really suitable for rubyforge or github, etc.
My question is, what is the best practice for ensuring we're all using the latest and greatest scripts across all users? We pretty much run these scripts on one server, but may need to expand to others.
Should we bundle them into gem(s) and start a private gem server?
Or something simpler like a common, shareable lib directory. Perhaps with a script to download/update from our SCM?
Other ideas?
Thanks....
This depends on some factors, like how many people want to change the code (only your team, or someone else too), or how much money you have for this?
Personally I'd create a build+gem server, where you can upload the scripts using some versioning system (like git or svn, depends on how many people are working on the project), and then create a cron job, that would automatically genereate the gems from the sources at generic intervals and store them as different versions. This way you can be sure that you always have an authorative server that stores your applications gems, and you can always get an earlier version if something breaks. Your script might create separate gem version names, like "appserv-edge" or "appserv-stable"
You might also want to check out github's closed source options too, if you have the money to afford that. I don't know however whether they have gem building and hosting facilities for non open-source programs.
I've created a private gemserver and it's dead easy. The only tricky bit is deciding how you want your users to upload gems. Personally, I just use a PHP upload form, and have it check to make sure that it's not masking any existing gems.
At my office we're using a bit of a hybrid approach for some of our shared scripts and libs. We do bundle them all in to a gem, but rather than using a gem server we keep them in source control, and then build the gem (using newgem) and install it locally as necessary.
The downside of this approach is that it takes two commands instead of one to install the gem, but this is largely mitigated in qa and production environments, since we use Capistrano for deployment.
The upsides are that it's dead simple, and in development there is a very short edit/build/deploy cycle if you're working with something that requires changes to the gem. I'm currently pulling a lot of common functionality in to the shared gem, so I'm really appreciating that aspect.