Discussion :

[ChPr]

Bonjour à toutes et à tous,

Un nouveau problème se pose à moi suite à l'utilisation d'un scrollView.

Avant que je n'utilise le scrollView, J'avais créé une méthode qui permettait de déplacer un opérateur dans la fenêtre en appuyant sur cet opérateur et en le déplaçant. En simplifié, c'est le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
planSchema.setOnTouchListener(new View.OnTouchListener() { // Action sur le plan Schéma
 
	@Override
	public boolean onTouch(View v, final MotionEvent event) {
		int action = event.getAction();
		switch (action & MotionEvent.ACTION_MASK) {
			case MotionEvent.ACTION_DOWN:
				boolean vu = false;
				for (int i = 0; i < listOpe.size(); i++) {
					if (listOpe.get(i).isConcerned(event.getX(), event.getY())) { // le touché est sur un opérateur
						opeCours = listOpe.get(i);
						vu = true;
						break;
					}
				}
				if (!vu) { // le touché est à côté d'un opérateur, on voudrait déplacer la fenêtre par le scrolling
					}
				break;
			case MotionEvent.ACTION_MOVE:
				if (opeCours != null) {
					opeCours.deplace(event.getX(), event.getY()); // On redessine l'opérateur à sa nouvelle position au fur et à mesure du déplacement
				}
				break;
			case MotionEvent.ACTION_UP:
				break;
		}
		schema.invalidate(); // On redessine le schéma
		return false;
	}
});

Maintenant, j'ai ajouté mon scrollView. Si je fais la même manipulation : j'appuie sur un opérateur et commence à déplacer le doigt, l'opérateur suit un court moment, puis c'est tout le schéma qui se déplace d'un bloc ; autrement dit c'est le scrolling qui déplace toute la fenêtre.

Comment pourrais-je modifier la méthode setOnTouchListener de telle manière que lorsque je déplace un opérateur, seul cet opérateur se déplace, mais si j'appuie dans un espace où il n'y a pas d'opérateur, c'est le scrolling qui agit.

Cela revient à faire le pseudo code suivant :

Si appui sur un opérateur :
- le déplacer,
- empêcher le scrolling d'agir.

C'est cette dernière instruction que je ne sais pas faire.

Merci de votre aide.

Pierre

[Hizin]

Après une rapide recherche, il n'y a pas la possibilité d'empêcher le scrolling dans la ScrollView même.
Sous-classe la ScrollView, rajoute-lui un attribut "locked", rajoute la méthode changeant la valeur de l'attribut puis, surcharge la méthode onTouchEvent. Fais-la renvoyer "true" directement si la ScrollView est verrouillée, fait un appel à super.onTouchEvent sinon.

Non-testé et vu/imaginé après une rapide recherche.

[ChPr]

Oui Hizin, c'est ce que je suis en train de voir sur la toile : cette solution

J'ai implanté cette nouvelle classe et modifié le fichier .xml comme suit : j'ai simplement remplacé ScrollView par LockableScrollView

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    tools:context="${relativePackage}.${activityClass}"
                android:id="@+id/AffSchema"
    >
 
    <LockableScrollView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:id="@+id/ScrollSchema">
 
        <RelativeLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:minHeight="480dp"
            android:minWidth="533dp"
            android:id="@+id/PlanSchema">
        </RelativeLayout>
    </LockableScrollView>
 
    ...

Quand je lance mon appli, elle plante sur la ligne : "setContentView(R.layout.base_appli);" avec le message suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

android.view.InflateException: Binary XML file line #9: Error inflating class LockableScrollView

J'ai le sentiment d'avoir oublié de faire quelque chose, mais je ne sais pas trop quoi .. un autre fichier xml ?

cordialement.

Pierre

[Hizin]

Pour les classes créées soi-même, il faut mettre le nom complet dans le XML, c'est à dire toute la chaîne de package + le nom.
Celles qui sont sans "namespace" sont uniquement celles d'Android.

[ChPr]

Le package de ma classe est : package com.example.sissy;

donc dans le fichier .xml j'ai remplace "LockableScrollView" par "com.example.sissy.LockableScrollView" .. j'ai le même plantage.

Qu'est-ce que je ne fais pas bien ?

Cordialement.

Pierre

[nicroman]

c'est quoi l'erreur exacte ?
(remonter à la source si nécessaire)

Il y a bien tous les constructeurs ?

[ChPr]

... Il y a bien tous les constructeurs ?

C'était là le problème.

Lorsque j'ai chargé cette classe sur le net, elle ne possédait pas de constructeur et, j'ai dû avoir une erreur me l'indiquant. J'en ai mis un, le plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	public LockableScrollView(Context context) {
		super(context);
	}

mais apparemment, cela ne suffisait pas et l'erreur indiquée : "android.view.InflateException: Binary XML file line #9: Error inflating class LockableScrollView" ne m'a pas orienté vers ce manque de constructeur.

De fait, lorsqu'on utilise une classe et qu'on y fait appel via un (par exemple) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

scrollSchema = (LockableScrollView) findViewById(R.id.ScrollSchema);

C'est le compilateur qui se charge d'aller chercher le(s) constructeur(s) ; c'est transparent pour l'utilisateur. C'est la raison pour laquelle je n'ai pas cherché dans cette voie.

NOTA : par cette explication, je ne cherche pas à me dédouaner de mon manque de connaissance de Java/Android.

Cordialement.

Pierre

[nicroman]

Non non, le constructeur sert à créer l'objet lui même (ce que va faire l'inflate du XML: transformer des données XML en objets java en mémoire).

La ligne que tu as écrite est juste un "cast":

On dit au compilateur:
Fais l'appel "findViewById(xxxx)" (le résultat est une "View")

Quand on dit "on reçoit une View" en java, on veut dire "on reçoit une référence sur une instance d'un objet de type View" (donc suivant la règle d'héritage "est-un": potentiellement n'importe quel objet dont la classe hériterait de View).
(on comprendra aisément que l'on puisse préférer la première forme un peu plus courte).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

View toto;

est donc la déclaration d'une référence (pour l'instance non assignée) sur un objet de type View.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

toto = findViewById(xxxx)

va assigner à cette variable une référence à l'objet (de type View) qui fait partie de l'arobrescence des vues, et qui a comme identifiant xxxx

Jusque là on reste dans du Java simple.
Quand on fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LockableScrollView toto = (LockableScrollView) findViewById(xxxx)

On fait trois choses:
* On déclare un référence sur un objet de type "LockableScrollView", cette référence s'appellera "toto".
* On fait l'appel à findViewById (voir ci-dessus) (qui renvoit lui une référence sur un objet dont tout ce qu'on sait c'est qu'il est de type View).
* On dit au compilateur: mais je sais que l'objet de type View retourné par l'appel *est-un* LockableScrollView... vérifie-le [s'il te plait ou pas] (on risque à ce moment donc d'avoir un ClassCastException si on a menti au compilateur), et assigne la référence à "toto"




Le constructeur, lui c'est autre chose, c'est le truc qui est appelé quand une instance de la classe est construite... bref quand on fait: "new XXXXX" on demande au compilateur de générer (en mémoire) une nouvelle instance de type "XXXXX".
La construction de cette instance peut nécessiter des paramètres, voir avoir plusieurs modes de construction, et donc plusieurs "constructeurs".

Dans le cas qui nous interesse, c'est le framework Android qui se charge d'instancier les views lors de l'inflate d'un layout par exemple (setContentView ou LayoutInflater.inflate...)
Hors pour ce faire, Android utilise un constructeur à base de Context et d'AttributeSet: http://developer.android.com/trainin...l#subclassview

Donc il faut *à minima* proposer ce constructeur, sinon, Android sera incapable d'instancer la view.


Mais normalement il écrit bien la raison de l'échec dans le logcat...
En particulier dans les causes originelle de l'exception finale...