need help
on classic thunkable we can change firebase setting on screen block using firebase component, but on thunkable x i just found on app setting. if i want to change firebase setting on screen block how do it on thinkable x?
Thanks for the request @arezmr6, we’ll looking to this for you.
Is there any particular reason why you need to be able to dynamically change Firebase settings after the app is installed?
For example, why don’t your default settings suffice?
Thanks.
@domhnallohanlon thanks for reply
i plan to make app with dynmic db that any one can create firebase using our template by import json structure. so i need change to firebase url and token settings flexible.
Hello @domhnallohanlon / @jared @jared / @Thunkable_Staff !
There is some progress on this suggestion/request? Or at least do you have serious plans to implement this?
I’m working in a project that will need connect different Firebase Databases, and today I need to build an App for each database 
Thanks in advance!
Regards
Paulo Vaz
Do all of your clients use the same schema in their database?
Not really for this project. Let me explain why:
As my projects handle a lot of “denormalized” data in Firebase, I created an application called “Firebase Surgeon” to speed up my projects in the design, testing and post-implementation phases (Some screenshots at the end of this post).
The idea was create a “Pocket Firebase Console” to facilitate the administration of the data, since the Firebase Console is not friendly on smartphones, and does not have functions such as renaming, copying or moving nested buckets or searching data throughout the database, just to name a few. And honestly, I don’t want to pay for a third-party product to have these basic functionality.
Looking at the satisfactory results I’ve gotten with this development so far, I see potential not only to extend the app’s functionality, but also to make it freely available to download at Play Store / Apple Store. My plans are to offer this app as a freeware (not open source) in gratitude for the great community support.
I also have plans to improve advanced features like automatic data generation, data import/export, data conversion to other formats turning the tool into a true Swiss Army knife for developers.
But… As in Thunkable the Firebase connection is “hardcoded” in the project properties, it is impossible to publish the application on the Google Play Store or Apple Store, as each user needs to connect the tool to different databases according to their needs /projects . So the only way nowadays would be to provide the tool as an open source application.
That’s why after found this post I asked if there are plans to have the Firebase connection setting available to be changed at runtime.
Can you help me to influence the staff to implement this feature in Thunkable in the near future?
Regards,
Paulo Vaz
2 Likes
Check this
https://x.thunkable.com/projectPage/619e8d851d818001049945c2
This is only the login portion but the idea is to use Firebase without having to hardcode the API and the Database URL.
Have Fun Thunking.
Hi @muneer!
This is fantastic!
But…
The current RealtimeDB Get and Save blocks and the cloud variables will not work with this approach… It means that it would be necessary to rewrite all the read and write routines to do via API, right?
If so, it’s honestly like reinventing the wheel, other than the time spent just to have this free tool working for other people than me…
I’d rather invest that time in deploying more advanced features like automatic data populating, exporting to other formats, import JSON files among other things…
Isn’t easier if the staff “opens” the connection setup to be changed at runtime?
Anyway, as usual you always show us different ways to obtain what natively we don’t have in Thunkable! I really appreciate your kind attention!
Regards,
Paulo Vaz
2 Likes
This is the easiest part.
The URL of your API is the Database URL part + the bucket or the path to your required key + .json
Do this and you will get the JSON value of that key.
You don’t really lose any thing, you will replace the DB Get block with API block using a simple 3 part URL.
@jared had shared the planet names from his Firebase account using this
https://jared-gibb-project-123-default-rtdb.firebaseio.com/.json
See this link
2 Likes
Hmm… I got “Code: 400 || Message: EMAIL_NOT_FOUND” when previewing this with my Firebase console email address.
1 Like
@tatiang, I can’t login either… but first, “wrong password”, and now “too many attemps to connect try later”
I will keep trying…
Sure @muneer if I move my app to use the Firebase API I get powerful features and more control over data manipulation, witch is very desirable for an APP like this.
The best reason I would consider this change is because it “seems” like we can control the amount of data loaded when reading a database in real time. And this is very useful, because in my application I do a “full node read” every time the user changes the path, to fill the Listviewer with Firebase data, identifying when it is an object or a simple value.
And at the root level ("/"), or any child node you can have literally Gigabytes to read and transpose into device memory. So if you “page” the data, you’ll of course save loading time, and you’ll also save money since Google charges you for the data traffic you generate. To avoid this constant reads I’m thinking in use a “listener” to detect changes to save time and data traffic (maybe my next implementation in the project).
But to be absolutely honest, I still don’t have the knowledge and time right now to spend on this low level development, and as I’m not familiar enough with this API, I’d have to study it, as I’ve never done anything like this (in fact, there are a lot of things that I never did and I’m learning thanks to you).
Thinking out loud, maybe if we do collaborative development on this tool, when it’s ready we could make it available for free (with ADs for the unpaid version). If anyone is up for the idea, I’ll be happy to share the project, and do this partnership.
Or, simpler than that, if @Thunkable_Staff opens the Firebase connection configuration (this was my first request), I would already be able to release the tool in the app stores.
1 Like
Not only this, many developers in the platform forgot that these blocks provided to read data from and write data to Firebase do not work by themselves and this block simplicity means there are servers on the side of Thunkable to receive your request and convert it to API calls or SDK library calls to get you the data.
In the unlikely event of these servers fail for one reason or another, your users will not be able to login to your Firebase services.
Let me surprise you more, I’m not talking about users testing your app using Thunkable companion app, I’m talking about users who downloaded and installed your app from App Store and Play Store.
Now, I’m not saying here that Thunkable servers will fail but just highlighting a fact that the simplicity of the blocks has a bottleneck behind it that very few developers consider.
1 Like
I fully agree!
And just remembering, I’ve seen Thunkable servers down a few months ago… Luckily it was a short outage (just a few hours), but imagine a mission critical app like the one I’m working on… An outage of just 1 hour will break all confidence in the product and severely impact the operation of the business (uber-like app).
Perhaps all this is an opportunity to learn and gain an extra level of independence, which is always welcome.
1 Like
In such situations, your app breaks not because of something wrong with the app but your app is using the Sign In / Sign Up blocks which rely on other servers to work making your app dependent on Thunkable servers even if your app is published.
1 Like
Exactly… When you develop your own database access/manipulation layer, connecting directly via Firebase API, you reduce the risks associated of this architecture, and get the advantage of a better data manipulation.
But of course, this is something very, very far from the “no-code” purpose of Thunkable, and not indicated for beginners like me, or for small projects…
But is something if I learn how to deal with, I will consider it to develop mission-critical apps in the future.
And of course for things like this, will be very welcome if Thunkable implements some missing features like Global Functions and a better organization in the variable access, among other improvements we as community are claiming.
1 Like
As far as I am aware, the calls are direct calls to the firebase endpoint and we do not proxy these calls. Do you have different information than this that would confirm the hypothesis?
Data calls I can confirm are currently proxied by Thunkable are for GSheets and Airtable only.
Scoped already and on the feature request board higher up than many other things!!
A quality of life improvement we have on our board!! (not sure where this one lies in priority)
[update]
@paulovaz72
here is an example that I made to handle this exact issue a while back. I just found it!
https://x.thunkable.com/projectPage/62265a9f1aadef00125058de
It’s certainly not pretty, BUT, you can hook into any firebase account dynamically (You’d probably need to refresh the webviewer. each time, but! it’s a start!
and here’s the HTML you’d need to include if you want to take a peek!
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1">
<script src="https://thunkable.github.io/webviewer-extension/thunkableWebviewerExtension.js"
type="text/javascript"></script>
<script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-app.js"></script>
<script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-auth.js"></script>
<script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-firestore.js"></script>
</head>
<body>
<span id="messageDisplay"></span>
<br />
<button type="button" id="messageButton">Click to send a message to the app</button>
</body>
<script type="text/javascript">
//when the page loads, get the message from the app and display it
window.onload = function () {
ThunkableWebviewerExtension.postMessage('ready');
}
ThunkableWebviewerExtension.receiveMessage(function (message) {
//pass your firebase info here
const configData = JSON.parse(message);
firebase.initializeApp({
apiKey: configData.apiKey,
authDomain: configData.authDomain,
databaseURL: configData.databaseURL,
projectId: configData.projectId,
storageBucket: configData.storageBucket,
messagingSenderId: configData.messagingSenderId,
appId: configData.appId,
measurementId: configData.measurementId
});
// Initialize Firebase
firebase.auth()
var db = firebase.firestore();
});
// when we get a message from the app that needs a return value
// return the string 'fast response' unless the message is
// 'slow message'. If the message is 'slow message', wait for
// four seconds, then return the string 'slow response'.
// The slow response shows how this could work for API calls that
// take time to execute.
ThunkableWebviewerExtension.receiveMessageWithReturnValue(function (message, callback) {
//login in to firebase
const email = JSON.parse(message).email;
const password = JSON.parse(message).password;
firebase.auth().signInWithEmailAndPassword(email, password)
.then((userCredential) => {
callback(JSON.stringify({
message: 'success',
user: userCredential
}));
})
.catch((error) => {
callback(JSON.stringify({
message: 'error',
error: error
}));
})
});
</script>
</html>
2 Likes
The issue reported in this post [Solved] All published Apps stop Working! Urgent help please! was effecting all and I myself was not able to login using the blocks but was able to login using the API endpoints.
I would stay away from a web viewer if I am targeting the independent run of the app from Thunkable server, I do not know for sure but it is issuing an iframe element which need to reside in a server.
A quick look through our codebase would indicate this is not the case, however I will check with @wei
He did post in that thread the items we are involved with, with no mention of firebase. I also asked this recently and was informed the same as below. which he reiterates here.
Typically, Firebase libraries manage the token for the user. I’m fairly certain the same happens here.
1 Like