We are planning to develop a new application that should offer:
Android-capable
Turn by turn with voice navigation
Offline maps (and perhaps routing?)
Satellite maps
Truck issues
As fas as I can see, all of the requirements (but the offline routing) is included in different Here Maps developer plans. Nevertheless, I still have some questions:
On their web (https://developer.here.com/plans/api/consumer-mapping), there are two main divisions (API plan and Mobile SDS plans). Which one is better for me and what is the difference?. I mean, it seems clear that I should go for the mobile plans, but not sure if this will be limiting my development in the future.
There appear no pricing options for the Mobile SDKs. We are planning to make the app available to our customers on a free basis and they will be charged for enhanced services. But seeing that API plans are based on a volume basis... how does the mobile plans work? (does it have any cost depending on the number of transactions too?).
Finally, customized POI are the main advantage of our app and is closed to other users (will no be made publicly available). Does the Here api include the option to add our POIs coming from another (ous) database on the fly?.
Thanks in advance,
Jose.
Turn by turn guidance will be only available via the (Premium) MobileSDK. Via REST APIs you can get routing, but not TbT voice guidance. Also Offline is only avaiulable via the Premium MobileSDK. Beside this, the native MobileSDK offers native vectorbased map rendering, when you use the REST APIs you would need to use the raster tiles. So in a nutshell: if you target Mobiles, you should definitely go with the MobileSDK. If you need any feature that's only available via web APIs (platform extensions, isoline routing, and some more), you can still combine these web APIs with the MobileSDK.
Pricing depends on your usecases, so you should discuss your usecase with HERe Sales: https://developer.here.com/contact-us?interest=mobile-sdk#contact-sales
Customized POIs is quite general, but of course you can load datasets from your servers and show them as POIs on the map, but you could also use the Platform Extension CLE, that also allows you to search within your dataset and is seamless integrated in the MobileSDK already.
Related
What's the difference in using the android API and the REST API? Are they equivalent? Can I do the same thing in both?
What are the limitations of one and the other?
I intend to start developing a mobile APP with HERE MAP.
There are 2 flavours of the HERE Mobile SDKs at the moment: Starter and Premium edition.
The starter edition is more or less identical to the REST interfaces and is using it also under the hood. It takes away all the boilerplate code you'd have to write (map tiling, fetching tiles and tile scrolling, REST requests to al the services and converting it into local objects, and so on).
The premium edition is using the HERE Hybrid engine instead. This means a lot of the services also work offline and run directly on your device, the mapdata is a special vector format that is also downloaded on your device, and you use online services and offline services mixed.
The premium edition has (beside offline capabilities) also some additional features you won't get in REST or in starter SDK, like turn by turn guidance or LiveSight.
I wanted to know which one is easier to implement. In the branch app indexing method is it required to implement app content sitemaps?
Full disclosure: I'm the Branch.io team
The way Firebase and Branch implement app indexing is fairly similar. In fact, Branch uses exactly the same methods for indexing as Firebase does, and adds some additional functionality on top. Branch acts as a wrapper for your own website, or as your full hosted website from the perspective of Firebase. So, when it comes to indexing with Google, you index a Branch link whereas Firebase requires you to submit your own site.
From the perspective of a developer, assuming the only thing you're trying to do is app indexing, Branch is slightly simpler to use and gives you rich analytics about the traffic from this channel but neither one is a lot of work. However, both platforms also provide other features that may sway your decision. If you're doing any sort of content sharing (i.e., your users create links to post on social media), Branch gives you app indexing basically 'for free' in the same library, whereas Firebase would require you to implement both features separately.
Both tools are free to use.
Firebase
Offers a lot of features (of which app indexing is just one), all implemented to a 'fairly good' level. This makes the Firebase platform an attractive choice for a small, new app that needs a lot of basic infrastructure and doesn't necessarily plan to require advanced functionality later on.
On Firebase, App Indexing for Android apps is implemented via integrating the Firebase App Indexing SDK and making a verified link between your website and your app (usually via Digital Asset Links or the Google Search Console). The 'Firebase App Indexing' SDK is actually just Google's old App Indexing SDK that's been rebranded and repackaged in a peculiar way.
You then register content items inside your app using the SDK and cross your fingers in hopes that Google will index them — there's no feedback on the process. App Indexing for iOS apps is based on crawling URLs that have been enabled for Apple's Universal Links. There is a Firebase App Indexing SDK for iOS, but to be honest I have no idea what it does. We've never seen any benefit or change to indexing behavior on iOS when it's integrated. On both platforms, you need to already have a live website, because every piece of content inside your app must also correspond to a specific URL on your site.
Branch
A best-in-class, enterprise-grade tool for growth attribution and content sharing, used by many of top apps like Pinterest, Airbnb, Jet.com, etc.
Branch is based around the concept of a single link that works everywhere, on all platforms, and intelligently redirects to the appropriate destination. Every time your users share content or view a piece of content in your app, that action generates a link. Since Google's search index is really just a huge collection of links, this is a perfect match.
On both Android and iOS, Branch de-dupes your app's links for any that point to the same content, packages up the result into an 'app content sitemap' (you don't have to do this yourself if you're using Branch links — it's automatic as soon as you enable the feature) and ships that sitemap file over to Google. In addition, since your links are hosted by Branch, there is no need for you to have an existing website, and you also get access to things like iOS Spotlight Indexing. Branch is compatible with iOS Universal Links by default, and we take care of verifying the connection between your web content and your app. We also monitor the links so we can give you feedback on if/when Google decides to index your content, and so that you can pull out reports on traffic that comes in through app indexed links.
On Android, in addition to the approach above, the Branch SDK helps you to identify pieces of content inside your app and submit them to Google for indexing. This is exactly the same approach as Firebase uses, except since the traffic still goes through a Branch link, you get additional data for attribution and analytics.
Feel free to read the full Branch Google App Indexing integration guide for more details!
Of course, implied in all of this is the assumption Google actually cares about your content enough to display it in search results. They seem to be getting better about this, but at the moment it's still very much a black box without much feedback to you as the developer. At Branch, we're trying to provide as much insight into the process as we can, so at least if your content isn't being indexed by Google you'll know that instead of being left wondering.
I've been asked to develop a .NET web application with the following requirements and features:
Moderate software license expenses
.NET Web Application
Document storage (with change history, although a complete CMS is not needed)
Complex data model
Extensible and groupable object attributes
Private/public field visibility
Non-trivial relationships between database tables
Custom alert configuration (screen and e-mail notifications) about approaching due dates, missing documentation, etc.
Resource access control & user management (roles and groups)
High user volume (several thousands of users)
Many complex and dynamic forms
Search engine
Statistical reporting
Bulk data & metadata upload and download
Simple data migration
REST API for external integration
Multilanguage
Full-featured mobile version (for tablets and smartphones)
Corporate look and feel
These are the options I have considered:
SharePoint Foundation 2013 + Custom Web Parts + Custom DB + Document Libraries
Sense/Net + Custom Web Parts + Custom DB + Document Libraries
Custom ASP.NET Web Application
What approach would you recommend? Also, can you please make a recommendation on the following points?
Server characteristics and topology
Application architecture
Scalability
Search capabilities
Reporting tools
Persistence framework
Document storage (MS Office)
Mobility
First of all, I work for Sense/Net, which I want to put out there to be fair.
However, even if I wouldn't be, I'd still recommend looking at our solution based on the criteria you outlined. What you are planning to build seems to be really custom stuff and from experience, I can say that projects like this never changing. Going for an open-source application would definately be my choice, in order to make sure I don't hit a wall later down the line.
Sense/Net is practically capable of delivering everything you need out of the box, but of course, customization will be needed.
From a licensing perspective, you would also be better off probably, since we only lincense the CPU cores, not the thousands of users benefitting from the system.
Writing a custom application from scratch with these requierements would make no sense in my opinion as the costs would be well over the one of a readymade solution (whichever you choose).
The things need to be clarified are the reporting tools you will need and whether you need a native application for mobile devices (or would something working in their browsers would be sufficient).
I can see that this answer is well overdue, but if the topic is still of interest and you havent done so yet, drop us an e-mail through our website and we can help you out in finding the perfect solution!
Short Version (tl;dr):
Is there an open source or commercial engine that provides embeddable collaboration and microblogging functionality?
Long Version:
I am creating a niche application that has need of this functionality and do not want to reinvent the wheel. The following are must have requirements:
Data API only. My application is SaaS, and I want to build the functionality around the data. This eliminates most of the offerings out there (facebook, salesforce chatter, yammer, present.ly, teambox)
Does not require use of a built-in front end. I really just want an engine that will take care of the storage and events, and gives me a means of querying. Requiring the use of a specific front end renders it useless for embedding into my app. This eliminates everything else I have found (status.net, Yonkly, Jaiku)
Beyond standard updates and replies, can handle custom events. For example, if I were embedding this into an logistics application, I could have the engine handle events like "shipped", "received", and "cancelled".
Beyond this, there are several nice to have features that a framework would have:
Should not require a specific platform or server technology to run (i.e. something like a RESTful API would be nice)
Should be message based so that commands that affect its state can come from any source
Should encapsulate its own storage so that external resources are not necessary (i.e. no database needed)
Should have pluggable extendable UI components/widgets for web, mobile, and desktop clients
Should have search and retrieval APIs available for many languages/platforms
It seems that someone out there should have this already, or at least be in progress with it. Please point me in the right direction.
Since nobody had any answers and continued research did not find anything, I created a solution on my own called Collabinate. Updates can be found on Twitter, and the project itself is hosted on GitHub.
I am building a new web site in asp.net, and im newbie with using maps.
For my web site i will need the following functionality:
display a map of specific location.
display route map between two or more location
calculate distance between 2 locations.
I found most of the functionality at the Bing Maps interactive SDK site:
and it works fine.
My questions are:
does it cost money to use this SDK ?
for the third task, i understand that i will have to use MapPoint Services.
(is there another way??) does it code money to use it?
I will really appreciate it if you dont send me links, cause my english is not the best one...
thanks a lot
It sounds like you're at the decision making stage of your project and weighing up the pros and cons of various frameworks. Due the nature of developing commercial applications using maps (supplied by Google, Bing, Yahoo, or any other map provider), it might be an idea to code against a library called MapStraction.
It allows you to easily swap and change map providers depending on commercial and/or customer requirements. It also provides a consistent interface so changing your map provider half way through the project isn't a big deal.
Have a look at using OpenStreeMaps. It's completely free, and so far I have been very impressed with it. In my area, it's more accurate and detailed than Google maps.
In the UK OS maps are also free.
Bing Maps is a good option. If your website is public and the map is publically available, then you can make use Bing Maps for free if you have less than 125,000 page views (similar to a session) of your map page in a year as noted here: http://www.microsoft.com/maps/product/licensing.aspx
If you expect a higher volume of usage then you would need a license. Note that Bing Maps licenses tend to be cheaper the Google licenses. This is pretty neat as Bing Maps has much more data than Google.
Also, MapPoint Web Services are not need, nor do they exist anymore.
Read the licenses carefully, both Bing and Google Maps cost money, if you use it for commercial purpose.
E.g. read this blog post:
http://www.47hats.com/2009/07/google-maps-the-10k-gotcha/
However, if you using it for your non-commercial app, it is free.
Another option to consider for those looking at this thread is Azure Maps, Microsoft's newer enterprise mapping platform. It usually costs less than Bing Maps and provides more features and services. It is also a part of Azure which make things a lot easier if you are already developing in Azure. Find more information at https://azure.com/maps
You can do all of that using just Bing Maps. The Bing Maps routing service can b sued to calculate the driving distance between two locations. If you want the straight line (as the crow flies) distance then it's just a simply calculation.
For Bing Maps you will always need a license, however there are free licenses. If you qualify for free usage depends on your use case. There's a good tool available for figuring out if you need an Enterprise license or if you qualify for free usage here: http://www.microsoft.com/maps/Licensing/licensing.aspx