This project is licenced under the GNU GPL v3.
Vitality will almost certainly stop working as of May 8th, 2018. For a brief explanation of why and for links to more detailed information check out this Third Party Developer Blog from CCP.
EVE Online has had at least three entirely different and incompatible API systems:
- XML API - the oldest of the three, largely supported by Vitality
- CREST - the middle child. Not at all supported by Vitality
- ESI - the latest and greatest. Again, no support by Vitality
The problem with both the CREST and ESI API's is that they require a developer key to be embedded in the application. This means that an enterprising user could extract the key and pretend to be that developer for nefarious purposes. I (Bleyddyn) am not willing to risk that and as far as I know, there is no way around it. Most of the example code I've seen assumes a web application where the developer key would remain safely on the server, not accessible to users.
I (still Bleyddyn) have been the only person working on Vitality for a couple of years now. Given how little I've been playing EVE and the above problem I don't think I'll be working on switching Vitality to use ESI.
Vitality has no tracking code so there's no way to know how many people use it, nor is there any reasonable way to contact people who do. So I have no idea how many people this will impact. If there are enough people who still use Vitality, then there's a chance that one or more of them will step forward and keep it going. One of the few good points is that most of the XML API specific code is at least reasonably well hidden behind classes which should minimize the amount of code that needs to be changed, as long as ESI really does cover all the same functionality as the XML API.
I created a project issue that can be used to discuss the problem, or just to commiserate with fellow Vitality users!
Vitality is a self-contained application, so download one of the .zip files from Releases and double-click to uncompress it, if necessary. Drag the Vitality application to your Applications folder, or wherever you want it.
The first time it's run Vitality will install a database with parts of the EVE Online static database. That and all other Vitality files are in this directory: ~/Library/Application Support/Vitality.
You may see a Gatekeeper related error when you try to run Vitality: “Vitality” can’t be opened because it is from an unidentified developer. The only way around that is to disable Gatekeeper:
Go to System Preferences, then "Security & Privacy", choose the General tab, Click the lock to make changes and make sure that "Allow apps downloaded from:" is set to Anywhere. (Directions are for OS X 10.9, but should be similar for newer versions of OS X)
Alternatively, you can right click on the Vitality app and choose the open command. You'll be warned that the app is unsigned, but you can open it anyway. After doing that once, you can open Vitality as normal.
Requires Snow Leopard and Xcode 3.2 It can be made to work on Leopard 10.5 with a little effort. The oldest current build machine is OS 10.9, Xcode 6.1.
The "Documentation" build target generates HTML documentation for
Vitality's classes; the documentation is added to Xcode's Documentation
and API Reference, and is also available in the Quick Help inspector.
Building the documentation requires appledoc, which can be
installed using Homebrew (brew install appledoc) or downloaded from that
project's Github releases page.
N.B.: As of April 2014, appledoc does not build using the latest version of XCode; if the HTML documentation is desired, install appledoc using the binary release.
Vitality uses Sparkle to manage updates and can be found here: http://sparkle.andymatuschak.org/
Quasi design document:
The Private/MainController.m file is where the execution starts. first in init, then awakeFromNib will be called, then appIsActive. After that the program is up and running and ready for use.
Core: Core functionality, the user interface calls these classes to do stuff. Heavy lifting such as calculating skill plans, managing character updates, database access and skill tree and stuff is all in here. Core/Controls User interface elements Core/Character The character object and related support classes. Core/SQLite Database SQLite database implementation used for storing skill plans Core/Skills Skill tree and Skill plan related data. Views: The user interface is implemented in here, it will use the Core classes to perform its operations. Windows: Pop up windows that display info about a skill, ship, certificate etc. Private: Top level stuff that handles app startup / shutdown and manages the main window.
In the dbscripts subdirectory there is a series of scripts that's used to build the database that MET uses. It's a modified and heavily cut down version of the CCP database export, and is built by connecting to a MySQL server that hosts the CCP DB export and fetching and processing the required data. See the dbscripts/README file for more info.