I'm tired of advertising networks (except some good) who ban me even not my fault. I now maybe will run out of money to pay the server cost. So I'm going to build my own advertising network.
Im looking for good open source advertising network app/framework/cms in any language, no matter they function for CPM or CPC.
I've found some in Github, but I dont have experience with it.
I want to make my own "Adsense". something like that where people can register, login and manage their own ads.
have a look at openX
Related
I live in an area where net access is mobile or nothing. While I can occasionally get access by tethering a mobile to that network, it isn't often connected, and when it isn't connected, no local device will function on its own, no matter which protocol it uses. Why isn't there any kind of server/cloud resiliency built in where devices can communicate in a peer fashion like Apple's Bonjour (Rendezvous? I can't remember)? If I have an Echo device, I should be able to switch it on through an Alexa interface. I'm OK without speech processing which requires interpretation of commands through an AWS or Google or Apple or whatever cloud, but being able to locally control a switch seems as though the interface could be smart enough to route locally. I guess I may have just answered my question. It seems as though routes could be internally stored so as to not to definitely require a server. Can you imagine shipping a colony to Mars and all the IoT devices stop working? If you ask me, they should not require a branch variation or special programming in order to function.
From the experience of having sat down and built a few, there are a some key reasons why viable IoT gadget products for the general market typically end up having to have a cloud-mediated mode, no matter what was envisioned when the design effort originally commenced:
General consumers (at least think) they want the option to control things when outside the home
Often even at home, a mobile phone may be on the mobile network not wifi, meaning that even if the user is physically inside their home, in network terms, they are not.
Firmware updates, dynamic content, etc are easier when they don't have to be relayed through a mobile phone or PC, especially a mobile that might sometimes have to jump networks partway through the process.
Ironically, having once set out to build an IoT product that could work entirely offline, the further the project progressed, the more and more difficulties that approach presented for general users, and the more the cloud path that was added as an option, started to look preferable in terms of how things should work all the time so that it could become the exclusive focus of development efforts.
My conclusion is that it's very hard to build an offline IoT gadget. Not only the developer, but also the users and marketing people need to understand and accept what sorts of difficulties and limitations that can mean.
So where does it happen? In the situations where the "users" are the "developers" - eg. open source. If you look around a bit, you'll find plenty of gadgets either built form scratch, or more commonly reverse engineered so they can run a custom firmware. Want a local RESTful API? Done! Want could relay via MQTT over SSL to your own broker? Done!
When you control the code, you control the mode.
But with products for the general market, most customers want things to work, not a lengthy technical explanation of why the details of their network setup mean they cannot.
I am struggling to find how to let google home do a local network rest call.
I have some ESP8266 laying around with mDNS and rest api in them.
Now with the google home I want it to send a rest call to the device.
I don't want any web hooks / services like IFTTT. I don't want the communication going through these 3rd party services.
It should work like this google home gets input (google service to understand is oke). It retrieves the action (local network, url rest call with body). Google home sends the rest api call to the local device.
No need to have port forwarding / firewall changes.
The Google Home does very very little on-device processing. Sending out local network calls is not one of the things it does. Almost all processing, including IoT controls through the Smart Home API, are done through cloud-based services.
Update
I can't answer "why" it doesn't do this, since I'm not one of the engineers that built it, but I can make a lot of guesses about why.
For starters - it increases the complexity of the software and hardware on the device dramatically. Right now, the device is really little more than a microphone and a speaker, with a little logic to detect the hotword and then stream everything else to the server, and then get a result back and play it. Most of the rest of the code is likely to handle setup and configuration.
If the device has to also be a general purpose IoT hub, then it needs software and hardware for Bluetooth and possibly other signaling systems. It needs to be able to keep track of the state of other devices on the network and manage that in between power cycles of the device (or even handle interruptions in power for the device itself). Some of the implications of that may need to open up the networking on the device to receive messages, not just send them. It has to have more extensive network configuration - to understand what local networking is and not just what the local router is and how to deal with that configuration (and that configuration when it changes). These are all possible, to be sure, but increase the complexity and, in some cases, lower the security of a device.
And that might be reasonable... if there was significant value in doing so. But you've already stipulated in the question that the voice processing could be done in the cloud, so once commands are sent to the cloud and parsed there - why not also do all of the above (device and state tracking, changing, etc) in the cloud? Particularly since most IoT devices maintain cloud servers anyway because people also want to be able to control or monitor their home devices when they aren't on their home LAN. Having a dual set of commands (some for when you're local, and some when you're not) does make sense in some cases - but also dramatically increases the complexity of both the controller and devices, so most just rely on the cloud, again.
So while I understand why some people would like to have a nice little system that can just sent your play local REST server a command now and then, the reality is that to do this for a consumer system isn't that reasonable.
If you really wanted a system that can do this - you can continue in the hobbyist spirit and build something with the Assistant SDK and your favorite IoT platform.
The “local” API for Google Home is a bit limited. Here’s a doc from someone who reverse-engineered the API.
Looks like they expose Bluetooth and Alarms/Timers, and some limited configuration stuff.
https://rithvikvibhu.github.io/GHLocalApi/
If I wanted to, how would I create an app like MyWi, i.e. a wifi tethering app? What are the steps to achieve this functionality? What frameworks/libraries would I need to use?
The goal is not to try to get this app into the app store, but to have it for personal use, and provide it to others.
EDIT:
Nick pointed out the HandyLight app, an app that provided tethering capability disguised as a flashlight. So, it is possible to provide tethering functionality via a third-party app on a non-jailbroken phone. So how is this done?
I have sort of hit a dead end on my research for this :(
If you have access to a developer account (or know someone who does), you can build your own copy of iProxy, an open-source proxy app that handles this. You'll never find it in the App Store, but the source is available on github: https://github.com/tcurdt/iProxy
No jailbreak required, and it works well. Note that I wouldn't recommend using it too often, however, as carriers like to sell their own golden-egg tethering plans, and may ping you for the data usage.
If you release it to the AppStore, Apple will not allow it. That's why there aren't any out there. There was a flashlight app which had the hidden wifi hotspot in it until someone posted a review comment of "WIFI TETHERING!!11!!!!!". Then Apple pulled it.
The iPhone has built in WiFi tethering - they call it "Personal Hotspot", but unless you have an unlocked phone direct from Apple (ie you paid in full with no contract), then you will have to pay your network provider more money to be able to turn it on.
I am trying to allow people (from a URL) to connect to a calender/contacts from their iPhone, Blackbury or Android phone - what is the best way to do this?
I've had a bit of a read and it seems that CalDAV and CardDAV are the best way to integrate calenders/contacts, but how exactly can I do this? The internet seems to lack a standard way of how you can integrate this into a number of devices.
Which mobile devices support them? And is it possible to just provide a URL and then the calender/contacts just automatically sync!?
All of this assumes you have some sort of Groupware server setup somewhere which acts as the repository for this information.
For opensource you might want to look at a product called Sogo. Apple also do a caldav/carddav server written in python. They expect you to buy a mac server but you can download the code and run it from a pc or linux box. There's a heap of paid-for groupware.
You might want to check out the "opensource" client software written by the same kids who develop Sogo caled funambol. This claims to be x-mobile (all the ones youve mentioned anyway).
The idea behind all the *DAV protocols is that yes everything is done by Uri (this was actually specced by Tim Berners Lee in his draft for the web).
I've just been through this very same process and found only emerging standards, of which *DAV are the de facto ones IMO. HTC use MS active sync on my HD2 to sync my Gmail. Go figure!
Bedework is CalDAV/CardDAV server that allows you to hook your iPhone/iCal calendar and events.
I have used it and it gives you an url to sign in with in you phone calendar. The Bedework is a server you could install on you machine (it is provided with documentation; this is a good point to start with).
Android natively does not support Bedework. In order for Android to support the CalDAV you have to install an application that supports CalDAV, but I do not know if they work with Bedewrok or not.
In the case of android you could try using the CalendarProvider and the ContactProvider. You could refer to this : http://developer.android.com/guide/topics/providers/calendar-provider.html
I want to send some Text plus a image from one iphone application to other iphone app but restriction is I should not use a web server in between communication,Is there any way to fulfill it ?
Details: There are two independent devices and could be far enough say out of network. My requirement one app adds some text with a image and sends it to another iphone which can be at any long distance , and the app installed in another iphone will read that info and image into itself.
Actually there is a solution that meets your needs — and that fits to bbums answer:
Create a HTTP-Server on the iPhone, using cocoahttpserver. than you will ask some webservice like whatismyip.com for your public ip. with this your iPhone can be connected worldwide.
But very likely ur wifi-network is not forwarding your port to the iPhone. Ash.
And even if: Now it gets difficult. How to publish your ip from one phone to the other? hmmm... — I got it: I will exchange the information in a centralized space! In the web!
... wait — that would be a Webserver.
You see: Without any kind of server in the Web the users would need to exchange ip manually and have full admin power and knowledge about the local network.
So IMHO bbums answer is the only way to go.
PS: I am working with http server running on iPhones. In local network that works great, especially with bonjour. And you can use them over distance network — but only with reconfiguration of your router — something you shouldn't force your user to do
There is far from enough information to provide a specific answer.
two apps on two different devices?
are the two devices on the same network?
are the two devices both on WiFi?
do you need the user to receive a notification or something if the app isn't running?
If on same device, you can define a custom URL handler in the destination app and then openURL: in the source app to pass the data over. Encode your image and text into the URL, but be careful of size limitations.
If on different devices, there are many possible solutions, but answering the above questions will be critical to actually knowing what solution is appropriate.
Given your comment -- two apps, different devices, arbitrary networks -- then you are going to have to have some kind of server in between. Note that the recently added Game Center does have the ability to rendezvous two users, but it has a very particular user experience that may not be appropriate to your needs.
I would suggest that you investigate using push notifications to notify the receiving user of the availability of content. As for moving the content between, no direct connection is possible and you will have to have some kind of store-and-forward server in between. And, yes, a web server is going to be the easiest possible solution simply because HTTP is ubiquitous these days.
If there's no network of any kind available, but both parties have amateur radio licenses, then hooking the two devices up to HF packet radios might work.
THIS is super EASY.
I would code up some software that can turn data into modem signal, like the good old dial up modem. The device would actually make those annoying buzzing sounds.
You get the phone number for your friends nearest landline and call him.
He places his iPhone near the phones receiver in listen mode and you connect to his phone using your audible modem.
Bingo, via the power of sounds you have sent data which is decoded on his device and all for the very cheap price of a phone call, there are pretty cheap these days especially if you use Skype.
Easy Way (relatively speaking)
A way two apps on different networks can communicate without setting up a web server of some sort is as follows.
Use an existing third party storage system like DropBox.
Each app would need the login and password for your DropBox. Then both apps can read and write files that the other app can see.
An existing app that does this is a shopping list app called ShopShop.
The app on my phone and my wife's phone both link to the same DropBox account and the app keeps the shopping list synced up when one of us adds something to the list.